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I. INTRODUCTION 



A. OBJECTIVE 

This thesis describes the prototype intranet specification development for a Coast 
Guard support command located at Alameda California. The purpose of the prototype 
intranet development project is to design an effective business model which will enable a 
collaborative environment and enhance the use of limited personnel resources. 

B. BACKGROUND 

Managing the proper maintenance and support of all electronics, 
telecommunications, and computer resources aboard all Coast Guard units located within 
the boundaries of the Eleventh Coast Guard District^ is not a trivial task for Electronic 
Systems Support Unit (ESU) Alameda, a small organization. 

Compounding these challenges, ESU Alameda^ recently experienced two major 
renovations that may alter their business model and existing culture: 

1 . The Coast Guard used downsizing and streamlining to meet the budgetary 
reductions required by federal agencies. Since the Coast Guard could not reduce the 
public services provided, several of the Coast Guard units which previously supported 
electronics equipment were cut and ESU Alameda was tasked with covering the additional 



' The geographic boundaries of the Eleventh Coast Guard District refers to all Coast Guard resources 
within the state of California, and any military vessels requesting assistance in California w aters. 

^ The Coast Guard uses four Electronic Systems Support Units (ESUs) on the w'cst coast. All are similar 
and are referred to by their acronym (ESU). follow'ed by their location, (i.e. ESU Alameda). 
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workloads.: As a result, ESU Alameda absorbed a small percentage of the previous 
resources and a complete organizational restructuring occurred. 

2. The command completed a phased workstation migration from a legacy 
proprietary computer environment to a new Windows NT networked platform. Although 
this presents an enormous learning curve for ESU Alameda employees, it offers the 
command enormous opportunities to enhance the existing business model and culture of 
the command. Despite the continuous improvements in commercial office automation, the 
prior use of proprietary computers required the generation of all forms and reports to be 
performed manually and offered little to no collaboration between employees other than 
the use of email. As a result, the time spent performing routine administrative tasks such 
as personnel issues, the ordering and tracking of repair parts, and the sharing of 
information required extensive use of scarce personnel resources. 

C. PERSONNEL AND SUPPLY TRACKING DATABASE SYSTEMS 

These two databases were specifically designed to reduce the command’s intensive 
time spent manually tracking both administrative and supply status issues. Working 
conjointly with the intranet they will help free up the available time of critical command 
billets currently over tasked as a result of the downsizing and streamlining initiatives. 

Microsoft Access 97 was used to build the system under a rapid prototype 
methodology. The intranet functionality will then be coded by another thesis student with 
the use of the Microsoft Internet Information Server (IIS) and active server scripting. 
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D. CHAPTER DESCRIPTIONS 

This section provides an outline of the different parts of this thesis. 

1. Chapter I Introduction 

This chapter provides a brief description of the business challenges facing Coast 
Guard Electronic Systems Support Unit (ESU) Alameda. The section concludes \vith a 
thesis content description. 

2. Chapter H Introduction To Intranets 

This chapter gives a foundation of intranet technologies and discusses how 
intranets are being used to solve business challenges. 

3. Chapter EQ Understanding The Client’s Business Environment 

This chapter discusses the history, organization, and structure of ESU Alameda 
and addresses new business requirements recently placed on the command as a result of 
Coast Guard restructuring (Streamlining). It addresses the current mission, goals, critical 
success factors and processes. 

4. Chapter IV Business Model Analysis & Design Plan Methodology 

Chapter four discusses the methodologies used to define ESU Alameda’s business 
model and explains how the critical processes and requirements were defined for use in 



prototype development. 



5. Chapter V Candidate Applications For Business Solutions 

Chapter five evaluates how different intranet applications could enhance ESU 

Alameda’s mission effectiveness. Several types of applications which would significantly 
enhance the business processes of the command will be presented and conceptually 
explained. Although few of the applications mentioned in this chapter will be part of the 
specifications development for this project, this chapter offers ESU Alameda potential 
applications to consider for future development efforts. Mission urgency and customer 
requests will dictate those used in the prototype development and analyzed in proceeding 
chapters. 

6. Chapter VI Analysis Of Client’s Business Processes 

After the interviews with ESU Alameda were complete, the data was analyzed to 

reveal possible ways the business model could be enhanced. This chapter discusses the 
methodology used to define the new business model and explains the use of data flow 
diagrams in performing this task. 

7. Chapter VII Rapid Prototype Design 

Chapter seven discusses the rapid prototype design of the intranet. The use of 
iterative database designs enabled a development that met the customer’s needs. Several 
screen shots are included to enable the reader to understand the uses of the database in the 
prototype development effort. 
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8. Chapter VIII Conclusion 

The final chapter briefly describes the need for ESU Alameda to establish a 
business policy for intranet use, and plan for organizational learning to get the most out of 
an intranet system. Although intranet security is not the focus of this thesis, a brief 
security overview and recommendations are provided. Finally, as a conclusion to this 
thesis, lessons learned are provided for future development considerations. 
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n. INTRODUCTION TO INTRANETS 



A. INTRODUCTION 

Chapter two will provide a working background of an intranet system and will 
begin by revealing a key reason why an intranet should be considered. This chapter will 
define the scope of the intranet and will show evidence of its rapid growth within the 
commercial sector. In addition, a listing of organizational benefits will be presented. The 
chapter continues by examining the various technical parts that contribute to intranet 
development, including a description of the intranet structure, uses of web servers and 
browsers, the chent server model, and intranet hardware and software requirements. 
Finally, a section of this chapter is dedicated to the use of the Production and 
Consumption Cycle to reveal possible ways a typical organization could gather, analyze, 
and share information by using an intranet. 



B. A TYPICAL REASON FOR AN INTRANET 



The Shrinking Federal Work Force ' 
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Figure 2.1 The Shrinking Federal Work Force, Ref. [1] 



The United States government is reinventing the way it operates in attempts to 
balance the budget and reduce the federal deficit. To accomplish this task, the work force 
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has been reduced as illustrated in Figure 2. 1 . This reduction in force strength means the 

remaining workers will now have an increased workload and must develop strategies for 

coping with additional tasking. An Intranet may be the solution to this cultural challenge. 

With the right corporate culture, intranets can become living, growing, 
organic ecosystems. They promote learning and spawn the innovation that 
allows organizations to do things cheaper, faster, and better [Ref 2, p. 
xiii]. 

Use of the intranet is not a new concept and has already been proven in the 

commercial industry. The federal agencies which choose to use this technology now, will 

be using a proven system to conduct business. 

...the use of intranets in the enterprise will grow 110 percent this year. 

...75 percent of all Fortune 1000 organizations will be running intranets by 
the end of 1998. ...more than 80 percent of Fortune 500 companies 
already have some kind of intranet in place [Ref 3, p. 80]. 

C. INTRANETS VERSUS INTERNETS 

The internet and intranet are very similar to each other with both using the same 

type of technology. The main difference between the two is the amount of privacy they 

offer. The internet is a public system while the intranet is a small-scale private version of 

the internet within an organization. This private version gives you a means to collaborate 

with other intranet clients using web browsers to instantly deliver information anywhere in 

your corporate network. Specifically, the intranet offers a highly interoperable, portable 

cross-platform system that is extremely scalable to the expanding functionality of an 

organization. Both types of systems use a Transmission Control Protocol and Internet 

Protocol known as TCP/IP. This TCP/EP protocol is used to carry packets of data over a 

network of computers. The internet and intranet technology also uses World Wide Web 
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(WWW) tools such as Hypertext Markup Language (HTML), Common Gateway 

Interface (CGI) scripting languages, and Java and Active X programming languages. 

All applications designed for the Internet also run on the Intranet. From the 
applications standpoint, there is no real dilference between these two types 
of networks. Typical Intemet/Intranet applications include web, e-mail, 
newsgroups, and file transfer (FTP) [Ref 4]. 

D. GROWTH OF INTRANETS 

The tools and capabilities that made the internet such a huge success are now 
letting thousands of companies share information inside their own organization. The 
growth of the internet and intranet is spectacular. The graph in Figure 2-2 is a single graph 
which includes everything related to the intranet including such things as growth in domain 
numbers, users, and access providers. The x-axis lists the years from 1990 to 1995 and 
estimates for 1996 to 1998. The y-axis reveals the amount of growth. 




Figure 2.2 Growth Of The Internet, [Ref. 2, p. 7] 
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Ian Campbell, Director of Collaborative Technologies for International 
Data Corporation (EDC), estimates that there were 100,000 intranet web 
servers in 1995, and that this number will grow to 4.7 million by the year 
2000. He also said that there were approximately 10 million Web browsers 
in use in 1995, and he estimates that number will be 40 million in 1996 and 
1 80 million in the year 2000. By any yardstick, that is phenomenal growth 
[Ref 2, p. 8]. 

There are several different classifications of intranets with each being specified by 
the function of their use. 

The Gartner Group classifies intranet proliferation and development into 
three levels. Level 1 intranets consist of low-level implementations, static 
publishing , or simply moving content on-line. Level II intranet 
development centers around enabling core day-to-day applications for web 
use and using the intranet as a workgroup computing platform. Level III 
intranets will be characterized by a large base of web-enabled applications, 
a consolidation of dozens of Application Program Interfaces (API’s) used 
in Level II, more secure web servers, and more powerful development 
tools. Most companies spent 1996 testing intranet waters at level I. 
Mainstream organizations are expected to develop Level II intranets in 
1997 and 1998. By 1999, top organizations are expected to plateau at 
Level m [Ref 3, p. 80-81], 



E. USES OF mXRANETS 

Once the intranet is established in a corporation the uses are almost endless and are 
largely dictated by the imagination of the designer and administrator. Many of the roles 
the intranet plays are very simple, requiring simple web pages created using HTML. 
Others can become extremely complex and sophisticated requiring special programming 
and links to developed databases. Figure 2.3 gives a graphical breakdown of ways 
corporations are currently using intranet technology. 
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How Intranets Are Being Used 
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Figure 2.3 How Intranets Are Being Used, [Ref. 5, p. 15] 



Here are a few examples of what may be found on a typical intranet [Ref 2, 



pp. 8-9], 

♦ Electronic Mail 

♦ Directories 

♦ Organization charts 

♦ Memos 

♦ Personnel manuals 

♦ Benefits information 

♦ Newsletters and publications 

♦ Systems user documentation 

♦ Training 

♦ Newsgroups 

♦ New extracts 

♦ Job postings 

♦ Sales reports 

♦ Financial reports 



♦ Customer information 

♦ Quality statistics 

♦ Vendor information 

♦ Product information 

♦ Marketing brochures, videos, 
presentations 

♦ Product development 
information and drawings 

♦ Inventory information 

♦ Network management 

♦ Asset management 

♦ Supply and component 
catalogs 
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F. THE ADVANTAGES OF INTRANETS 



There are numerous reasons an organization may want to set up an intranet. Here 
are just a few of the possible reasons: 



1. Tangible benefits of intranets [Ref. 2, p. 29] 



♦ Fast and easy to implement 

♦ Cheap to implement 

♦ Easy to use 

♦ Save Time 

♦ Provide operational efficiency 

♦ Save cost 

♦ Based on open standards 

♦ Coimect and communicate 
among disparate platforms 

2 . 

♦ Provide better communication 

♦ Provide access to accurate 
information 

♦ Capture and share knowledge 
and expertise 

♦ Provide better coordination 
and collaboration 



♦ Put users in control of their 
data 

♦ Secure 

♦ Scalable 

♦ Flexible 

♦ Provide the richness of 
multimedia 

♦ Leverage your infrastructure 
and applications investment 



♦ Provide for creativity and 
innovation 

♦ Provide new business 

opportunities 

♦ Provide new business 

partnerships through access 
by suppliers and customers 



Intangible benefits of intranets [Ref. 2, pp. 29-30] 



Intranets are relatively inexpensive to install and administer compared to other 
forms of group collaboration techniques such as long distance phone calls, 
teleconferencing, meetings, and some GroupWare products. Web browsers are available 
from several sources either for free or for a modest price, and many of the web servers 
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required are packaged with operating systems which may already be in place. An example 

of such an operating system is Microsoft’s Windows NT Server. Whereas many 

GroupWare products (unlike the intranet) are not fully interoperable and requires specific 

hardware, operating system, and network configuration [Ref 6]. A new study conducted 

by U.S. Computer and funded by Sun’s Internet Commerce Group indicates that web 

technologies can reduce internal corporate networking costs by as much as $ 1 1 million 

over four years for a large network [Ref 7]. 

The intranet operates on an open platform meaning that it acts as its own layer, 

independent of the operating system. There is no need to change the existing hardware or 

operating system already in place. If it is a standard system, then there will most likely be 

a browser available for it, making it intranet capable. 

The one hidden expense of setting up a corporate intranet is that you must 
run TCP/IP (transmission control protocol/Intemet Protocol), the 
protocols that define how information is passed around the internet, on 
your network. If your organization runs on TCP/EP now, then you’ve paid 
the price for more memory and new software in desktop PCs and more 
capable routers throughout the network [Ref 8, p. 107]. 

G. INTRANET COMPONENTS 

Each organization will set up an intranet differently. Some will consider the inside 
use of the web along, along with any specific web based applications, as their intranet. 
While others will also consider the actual computer network of the organization as part of 
the network. Here are some of the most common components of an intranet: [Ref 2, 
pp. 9-10] 
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♦ Network 

♦ Electronic Mail 

♦ Internal web 

♦ Newsgroups 



♦ Gopher 

♦ Telnet 



♦ Chat 

♦ FTP 



1. Network 

The first, and most complicated, part of any intranet is the network. The 
intranet is the network of many networks. In large organizations, the 
intranet may also be a network of networks. In smaller organizations, it 
may be just a singe network. At any rate, the network is at the heart of the 
intranet. The intranet canT exist without it [Ref 2, p. 10]. 

Organizations can use a variety of different technologies the link their computers 
together to form networks. The main design factors would consider such things as 
funding requirements, distances between computers, use of existing computer hardware, 
and the amount of security an organization requires. A simple type of network is a Lx)cal 
Area Network (LAN). A LAN serves only a single group of users within the same 
physical space. Examples of a LAN would be a military command inside the same 
building, or a department within an organization. As previously mentioned, LANs can be 
made up of varying types of technologies. Ethernet, Token Ring, and Fiber Distributed 
Data Interface (FDDI) are among the most common. A description of each follows: 
Network Types 

♦ Ethernet. Ethernet LANs consist of coaxial cables or twisted-pair (standard 
telephone) wire hooked to a device called a hub. The hub is the traffic cop 
that directs traffic along the network 

♦ Token Ring. Token Ring LANs consists of coaxial cables or twisted-pair 
wires attached into a Media Attachment Unit (MAU). The MAU simulates all 
devices being cormected into a ring. Computers on the ring take turns 
transmitting. A token passes sequentially to each device on the ring to indicate 
when it is their turn to transmit. 
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♦ FDDI. FDDI networks are similar to Token Ring Networks in that they also 
pass a token. However, they use fiber-optic cable instead of twisted-pair wires 
[Ref 2, p. 10], 

2. Electronic Mail 

Electronic Mail, otherwise referred to as e-mail, allows one person to compose a 
message and send it electronically to anyone in the world who has an e-mail address 
established. The receiver can also respond just as easily. With the improving of email 
software programs, email is no longer limited to Just text files. Users can now send 
formatted documents, presentations, sound files, and video clips just as easily as a text 
document. 

By default, e-mail is generally an organizations first intranet application. It 
provides the opportunity to communicate fi'om one person to another or to many people 
[Ref 2,p. 11]. 



3. Internal Web 

When people think about internets they are usually thinking about internal webs, 

however, the internal web is not synonymous with an intranet. It is only a part of it, but it 

is a very important part. Just like the use of e-mail and web browsers have caused the 

internet to explode, they have done the same for the intranet. 

The internal web is simply using Web tools inside your organization. It 
makes your corporate information easy to access. All users have to know 
is how to use a mouse to point and click. If they can do that, then any 
information they need can be available at their fingertips. With the addition 
of search tools to the internal web, if they can use a keyboard, the 
possibilities become almost endless [Ref 2, p. 12], 
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The use of the internal web will allow different divisions of an organization, or 
different teams within a division to collaborate and share information. This works 
differently than a typical network. For instance, a maintenance team may require logistics 
information from an unavailable supply division. Under a network system they would 
have to know exactly where the information was stored, and then possess the exact 
application required to view the data at their computer. Under an intranet, a search for a 
key word could be performed to find the needed file, and then that file viewed. This is 
because the internal web is not application dependant. This example of course assumes 
the security of the file allows access. 

The internal web consist of two major components. 

1 . Web Server 

2. Web Browser 

a. Web Server 

The web servers act as the hub for the entire intranet. They are computers 
which store all the web pages and use the Hypertext Transfer Protocol (HTTP) to send 
the needed page to a web browser (or client) when requested. 

b. Web Browser 

The primary function of the web browser is to act as a graphical user interface 
(GUI) between the user and the web server. For this reason, the web browser is also 
referred to as a client of the web server. More on this type of relationship will be 
explained later in this chapter. The browser portion of the internal web is physically 
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located on the user’s computer. The user uses the browser to request pages from the web 
server and download Hypertext Markup Language (HTML) documents. As web 
browsers have become more robust in their operation, they have mirrored themselves to 
work with other internet software tools within the same browser program. Examples of 
other internet related functions include e-mail, newsgroups, and File Transfer Protocol 
(FTP). The browser is a critical part of the intranet because it enables a common interface 
between all users and their shared information. With a browser on every computer, users 
are no longer required to have the same applications as a different department to view data 
files. The savings in software purchasing alone could become enormous as long as the 
original data is saved in the HTML format. 

4. Newsgroups 

Using a newsgroup with a web browser is similar to using email. The difference 
being that the information is published so everyone accessing the newsgroup can read the 
ongoing content instead of just a selected few. This form of communications also reduces 
the congestion of hardware resources since a user checks a newsgroup instead of everyone 
being sent the same email. This type of collaboration enables threaded discussion 
(continued discussions) where different people can ask questions or discuss topics of 
common interests. It also allows archiving of discussions where search mechanisms can 
be used to seek out answers to previously answered questions. Acting in a sense as a 
knowledge base for corporate information. 
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5. 



Chat 



Internet Relay Chat (IRC) facilitates conversations over the internet in 
close to real time. On an intranet, chats can take the place of long-distance 
phone calls between locations. They allow you to communicate ideas more 
quickly than through e-mail. Chats facilitate brainstorming sessions for 
participants who can convene at the same time, but not at the same place. 

You can schedule a chat about any topic of common interest and anyone 
can participate. You can also use chat for impromptu conversations [Ref. 

2, p. 19]. 

6. FTP 

File transfer protocol (FTP) provides you a repository of information that 
is readily accessible. Anyone with FTP can log in to the repository and 
download what they need to their computer. FTP works well for 
transferring files that are too large to send by e-mail [Ref 2, pp. 19-20]. 

A few ways FTP can be used on an intranet are; 

♦ Allow users to download software and patches 

♦ Allow web pages to be uploaded to servers 

♦ Permit file transfers of veiy large files such as drawings, project drawings and 
specifications and computer aided design files 



7. Gopher 

Like much of the internet, gopher provides text-only information. Gopher 
is menu-driven, making it easy for you to drill down through levels of 
menus to get to the information you need. Before the advent of the Web, 
gopher servers provided the richest repositories of information on the 
internet [Ref 2, p. 20]. 

Just like FTP applications are now part of the typical browser, gopher 
applications have also joined the browser role. To a large extent, the web has 
replaced the typical gopher servers previously used, but there may still be archived 
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information on gopher servers that could benefit an organizations intranet design. 
If an organization needs access to these large collections of government and 
university gopher servers or if the organization already is using a gopher server, 
then a gopher server is probably not needed on the modem intranet. 



8. Telnet 

Telnet allows you to log in to a remote computer. It typically provides 
access to resources that reside on remote mainframes. Telnet (TN) 3270 
allows you to access a mainframe and emulate a 3270 host-based terminal. 
A major use for TN3270 is to provide access to university library card 
catalogs and databases. You can use it to open up your mainframe 
applications to your intranet; however, it’s not as pretty as using the Web 
[Ref 2, p. 20], 



H. INTRANET TECHNOLOGIES 
1. The Client/Server Model 

To understand how the internet and intranet operates, it is important to understand 
the concept of client/server computing. The client server model as shown in Figure 2.4 is 
a form of distributed computing where one application (the client) communicates with 
another application (the server) for the purpose of exchanging information. Specifically 
the client and server perform the following functions [Ref 9]; 



a. The clients responsibility is usually to: 

♦ Handle the user interface. 

♦ Translate the user's request into the desired protocol. 

♦ Sends the user request to the server. 

♦ Waits for the server's response. 

♦ Translate the response into "human-readable" results. 
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♦ Present the results to the user. 
b. The server's functions include: 

♦ Listen for a client's query. 

♦ Process that query. 

♦ Return the results back to the client. 



Web Server Web client (browser) 




Figure 2.4 Client Server Dialog [Ref. 10, p. 8] 



Referencing Figure 2.4 for this example, a person uses the browser as their primary 
interface to interact with the application they desire. In this case, a user will run client 
software to create a query. The client then connects to the server in a method transparent 
to the user. The browser uses interpreters to interact with the intemet/intranet resources 
to access the information desired by the user. Both sides use URLs to describe the 
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protocols and locations of web resources without regard to the particular client software 
the user is employing to access them [Ref 11]. Using standard protocols the client sends 
the query to the server where the server analyzes it, computes the results of the query and 
then sends the results back to the client using established internet protocols. The server 
may also use other sever based programs to obtain the results, which are then sent to the 
client is similar fashion. Once received, the client presents the results to the user in the 
browsers graphical interface. Similar process occurs for many of the other client server 
interactions. 

Key WWW specifications include the Hypertext Markup Language (HTML), 
Uniform Resource Locators (URLs), Multipurpose Internet Mail Extension (MIME and 
the Hypertext Transfer Protocol (HTTP) [Ref 10, pp. 8-9]. These specifications are 
discussed as follows; 

♦ Hypertext Markup Language (HTML) - HTML is used when 
publishing a document that is to be displayed through the WWW. 

ETTML is a set of simple syntax commands that describes how a 
document is structured. This language allows the user to define the 
parts of a document, but not the formatting, so that the browser used 
for reading the document can format it best to suit the user’s display. 

♦ Uniform Resource Locators (URLs) - a URL is a complete 
description of an item, containing the location of the item you want to 
retrieve. A typical URL looks like this; http;//www.nps. naw.mil . the 
first item in the URL (portion that ends with a colon) is the protocol 
used to retrieve the item. For this URL the protocol is Hypertext 
Transfer Protocol. The two forward slashes that follow indicate that 
what follows is a valid host address. It can either be the text as shown 
or the actual corresponding IP address of the site. 

♦ Multipurpose Internet Mail Extension (MIME) - MIME is an 
extension to the existing Simple Mail Transport Protocol (SMTP) 
standards that offer a standardized way to represent and encode a wide 
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variety of media types, including textual data in non-ASCI character 
sets, for transmission via internet mail. 

♦ Hypertext Transfer Protocol (HTTP) - After it was decided to use 
hypertext as the standard format for WWW documents, a protocol that 
allowed these hypertext documents to be retrieved quickly was 
developed. This protocol is HTTP. HTTP is a fairly simple 
communication protocol that allows the document it is retrieving to 
retain hyperlinks to other documents during download [Ref 12, pp. 
117-140]. 



I. HARDWARE AND SOFTWARE REQUBREMENTS 

A computer system operating on an open system TCP/IP network can also run 
internal applications distributed over a corporate LAN by using an intranet. This is 
accomplished in a similar fashion that the internet uses web servers and browsers. 
Because the protocols used within the intranet are optimized for the low-bandwidth 
modem connections typically found in the internet environment, the intranet does not 
demand high speeds from any of its hardware components. Even though the intranet web 
server and browser form the heart of the intranet, it cannot exist without an existing 
computer network infrastructure in place. This infrastructure will have it’s own hardware 
and software requirements and will largely dictate the amount of CPU, RAM, and Disk 
Storage resources the system will require. Typical requirements to consider include; 

Requirements: 

♦ server machines and client workstations, which can include a mix of 
platforms (such as versions of Unix, Windows, and Macintosh), 
applications, and network services, all communicating via the TCP/IP 
protocol 
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♦ network backbone (LANAVAN), consisting of connections, cables, 
satellite links, bridges, routers, brouters, repeaters, and other 
components (Optional) backend databases, which can include a mix of 
legacy databases, departmental databases, data warehouses, and other 
data stores 

♦ Standard TCP/IP services, including Hypertext Transport Protocol 
(HTTP), Domain Name Service (DNS), File Transport Protocol (FTP), 
GopherS, Usenet news. Wide Area Information Servers (WAIS's), 
remote login services (Telnet), electronic messaging, and so on, 
running on server and client machines 

♦ All network resources are configured with IP addresses and 
communicate with other resources via TCP/IP. The network may be 
distributed across multiple sites. Information access is controlled via 
user authentication, firewalls, certificates, the Secure Sockets Layer 
(SSL), and other mechanisms 

♦ To deploy an intranet, your organization must have a fuUy operational 
TCP/EP network installed either throughout the enterprise or in the 
portion of the LAN/WAN on which you want to run your intranet 
applications [Ref 13]. 

♦ Web authoring software to create and update site content. 

Although the functional design of the network will dictate the majority of the 
hardware requirements for the intranet, there is a large degree of flexibility in choosing the 
software applications, servers, browsers, and scripting languages used. The designs of 
intranets, along with their software requirements, can vary in complexity depending on the 
design objectives of the intranet. On the simple side, static web pages are posted using 
easy to use office software such as word processors. On the complex side, information 
requires large streaming multimedia files, database and application interactions, and use of 
Common Gateway Interface (CGI) programs to meet desired organizational functionality. 
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Once the objective of the intranet is established by the organization, the choice of 
web server must be determined. Since web servers are continually emerging, each must be 
evaluated on flexibility, cost, and ease of use. Currently, Netscape FastTrack Server is the 
best bet for a no-frills server. Netscape Enterprise Server and Microsoft Internet 
Information Server (free with NT 4.0 server) are more industrial strength. They each 
contain security features, search engines, and ability to interact with databases. A second 
choice that must be made is the way the intranet web will be developed. Choices include 
programming in HTML, or use of many WYSIWYG editors that help develop the HTML 
code such as HotDog, FrontPage, and NetObjects Fusion. If the intranet involves 
interactions with databases then a Common Gateway Interface (CGI) program Avill be 
required for the database and web server to interact with each other. Common CGI 
programs include Cold Fusion, and Microsoft Active Server Pages [Ref 14]. Several 
elements determine which applications are best suited for the intranet design including 
budget, available time, developer skills, prior experiences, technical support, release dates, 
and current product reviews. 

J. INFORMATION CREATION AND CONSUMPTION 

...most users on intranets are not "webmasters", but rather business users 
who need to create and analyze information. Presentation is important but 
secondary. Their goal is to get their job done [Ref 15, p. 1]. 

An intranet offers little value to an organization if the consumption and 

distribution of data does not support the operational environment. For the most 

part, organizations access data, collaborate information, publish results and 
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generate memos, proposals, budgets, analysis, presentations, and supporting 
documentation. 

To take advantage of the new opportunities an intranet can offer an 
organization it must be willing to allow cultural change of the employees. 
However, there is a distinct danger that this change could pursue the adaptation of 
time consuming graphical displays instead of the creative collaboration of ideas if 
not properly managed. For this reason, adequate training in web publication and 
standards of content will be required. To maintain organizational unity guidelines 
can be established, but the enforcement and creativity of intranet use should be 
decentralized to each division to enhance individual productivity and effectiveness 
of the intranet. With different operational roles, each division will different ways 
to use the intranet resources to save time and maximize creativity among peers. 
Figure 2.5 introduces the information development and consumption cycle which 
focuses on the concept of developing relevant up to date information. 
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Figure 2.5 

Information Production and Consumption Cycle, [Ref. 15, p. 3]. 

The process starts with an organizational member having a need for 
information. 

The typical knowledge worker operates in the context of the information 
creation and consumption process. Their primary product is new 
information which contributes to the collective corporate knowledge base 
of information. For example, a knowledge worker gathers information from 
many sources, perhaps from the Internet, corporate databases or a Word 
document on the LAN. As this information is collected and analyzed, the 
user begins to create new content using familiar tools like Microsoft Office. 

In some this creation process involves several people and content is 
developed coUaboratively. Once this information is distributed others can 
access it and use it to drive other cycles of information consumption and 
creation [Ref 15, p. 3], 

The first step in the circular data generation process is to gather up to date and 
valid content pertaining to specific organizational requirements. Once sufficient content is 
collected the second stage begins. In the second stage the content is analyzed, clarified, 
and composed. Web based applications are used to create HTML documents capable of 
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bringing out the key concepts of the collected data so other members of the group can 
quickly gain the obtained knowledge base of new information. Finally, the third and final 
stage occurs where the data is published and collaborated among the various users within 
the organization to enhance team productivity. The iterative process creates and maintains 
an organizational knowledge base of relevant and timely data. As organizations develop 
their intranets they continue to learn and will select the specific publishing technology that 
best addresses their needs. 

K. CONCLUSION 

This chapter spanned a wide area of topics including reasons a government 
organization may consider developing an intranet, a background description of what an 
intranet is and how rapidly it has grown within the commercial sector. The chapter 
continued by defining numerous uses of an intranet and then defined several tangible and 
intangible benefits to using an intranet technology. It looked at the various technical 
pieces of an intranet and explained their purpose within the intranet structure. The chapter 
continued providing background material by offering a description of the basic concept of 
web servers and the use of browser within a distributed client server model, explaining 
how their functions enable the sharing of intranet resources. Intranet development 
planning was introduced along with considerations to be made in establishing hardware 
and software requirements. The chapter concluded by discussing ways a typical 
organization would gather, analyze, and publish information using the Information 
Production and Consumption Cycle to improve an organizations knowledge base of up to 



27 



date relevant information. The following chapter focuses on the mission of the Coast 
Guard’s Electronics Systems Support Unit (ESU) Alameda, located in Alameda 
California. 
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UL THE CUSTOMER 



A. INTRODUCTION 

The ability to use the concept of database design and internet active server 
scripting intrinsically motivated two separate thesis teams to work together as a design 
team and develop a prototype intranet for a receptive organization. The search for such 
an organization was limited to those willing to share their existing business challenges with 
the team, and to those who already possessed or would soon possess a technical 
architecture sufficient for intranet development. Ideally, the organization would be able to 
specifically identify and be in control of their critical requirements, be under extrinsic 
motivation to change existing business routines, and be extremely willing to discuss ways 
their business model could change to improve operational performance. 

This chapter focuses on Electronic System Support Unit (ESU) Alameda, which is 
a small Coast Guard command located in Alameda California. A brief history of the unit is 
provided, followed by a review of the command’s functional organization, and mission 
objectives. Finally, those forces extrinsically motivating the need for internal change will 
be introduced along with the command’s requests for the team. 

B. BACKGROUND 

1. Agency Overview 

The Coast Guard is the primary federal agency with maritime authority for 
the United States. It is a complex organization of ships, ^rcrafl, boats and 
shore stations. Decentralized, both administratively and operationally, CG 
personnel respond to tasks in several mission/program areas. A vessel may 
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carry out roles in law enforcement, search and rescue, marine 
environmental protection, maintenance of aids to navigation, and ice 
breaking. An aircraft may search for and assist distressed vessels, evacuate 
injured people, conduct pollution detection and surveillance flights, report 
sightings in conjunction with law enforcement, and carries out the mission 
of the International Ice Patrol [Ref 16], 

The Coast Guard forms a hierarchical organization which is geographically 
separated into two (west coast and east coast) similar platforms. Acting within the 
Commandant’s guidelines, the Atlantic Area and Pacific Area Commanders carry out the 
missions of the Coast Guard by directing each of their respective district admirals. Each 
of the several district admirals then uses their numerous commanding officers and 
operational platforms to actually carry out the missions of the Coast Guard. When 
technical problems arise, operational support is received from the respective Maintenance 
and Logistics Command (MLC Atlantic or MLC Pacific). To enhance the support 
capabilities of the single Maintenance and Logistics Command, specialized functional 
support commands are decentralized and geographically located in each district. Since 
there are several operational platforms scattered throughout each district, the support 
commands may further decentralize their technical staffs to increase effectiveness. As 
previously mentioned, the west coast Maintenance and Logistics Command uses four 
Electronic Systems Support Units (ESUs) to directly support the Pacific Area 
(PACAREA) Commander and four district admirals. Each ESU provides a similar role 
within their respective geographical boundaries and operates under the supervision of the 
MLCPAC Electronics Systems Division (t). Figure 3.1 provides the Coast Guard’s 
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hierarchical organization down to the Area, District, and MLC levels. The ESU is 
conceptually part of the MLC unit within this diagram. 
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Figure 3.1 Coast Guard Organization, [Ref. 17]. 



2. Mission 

The mission of Electronics Support Unit (ESU) Alameda is to provide complete 
and timely electronics, telecommunications, and computer related support to any Coast 
Guard unit operating within the geographical boundaries of the Eleventh Coast Guard 
District* (D1 1). Figure 3.2 portrays the area of responsibility and gives a good 

* The boundaries of the Eleventh Coast Guard District encompass the states of California, Nevada, Utah, 
and Arizona. 
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visualization of the magnitude of this task and the numbers of organizations supported 
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Figure 3.2 ESU Area Of Responsibility, [Ref. 18], 
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In addition to the units provided in Figure 3.2, ESU Alameda is also responsible 
for supporting all Coast Guard cutters transiting the waters of the Eleventh Coast Guard 
District. 

The scope of this technical support includes the provisions of timely maintenance, 
repair, and any form of technical assistance requested from an operational unit including 
technical advice. These tasks are accomplished by providing the following services under 
the authority of the Maintenance and Logistics Pacific instructions, specifically 
MLCPACINST 10550.1 (series): 

Contract Support 

The Eleventh Coast Guard District (Dll) Maintenance Contract is the primary 
means of providing preventative and corrective electronics maintenance to Groups, Air 
Stations, Patrol Boats (WPBs) and Stations within Dll. ESU Alameda administers and 
oversees this contract as the Contracting Officer's Technical Representative (COTR). 
ESU Alameda’s Quality Assurance Evaluators (QAE) constantly monitor the quality and 
performance of the civilian contractor to ensure timely and thorough support is achieved. 

Casualty Response 

ESU Alameda coordinates all maintenance and logistics actions required to quickly 
resolve equipment failures published as Electronic Casualty Reports (CASREP) for afloat 
and ashore units alike. Depending on the type of unit involved, specialized sections within 
ESU respond to each CASREP by arranging for technical assistance and/or corrective 



repairs through a private contractor or other resources. This is ESU Alameda’s number 
one mission priority. 

Telecommunications Support 

ESU Alameda maintains two telephone (TT) shops: one centrally located on Coast 
Guard Island in Alameda California which supports aU Northern California units, and one 
in San Pedro California which supports all Southern California units. These two shops 
maintain aU telecommunications systems which are not currently covered by private 
contract. In addition, these shops are responsible for the Bay Area Communications 
System, a very large Coast Guard owned microwave system. 

Project Assistance 

ESU Alameda acts as the liaison between the district staff elements and operational 
platforms and the Maintenance and Logistics Command electronics section MLCP(t). 
ESU frequently assists the Maintenance and Logistics Command or district staff in 
coordination of equipment installations and other project functions. 

Pipeliner Staging 

ESU Alameda serves as a staging area for Electronic Technicians (ETs) awaiting 
advanced schools for specific shipboard equipment. This assistance to Coast Guard 
cutters prepares the new technician to transfer afloat. While awaiting these schools, ESU 
exposes pipeliners to as many facets of the ET world as possible, including hands-on 
electronics repair and maintenance training. 
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As previously mentioned, ESU Alameda primarily performs ongoing electronics 
maintenance repair and project installations for other governmental commands located 
within the boundaries of the Eleventh Coast Guard District. Due to the nature of their 
jobs, ESU Alameda acts as liaisons with many organizations to provide funding, parts, 
logistics, and technical assistance. In addition, ESU Alameda works with both contracted 
and military sources as well as government employees both inside and outside of their span 
of control. 



3. Organization 

ESU Alameda is functionally and geographically organized to place support 
technicians and contract shops as close to their customers as possible while maintaining 
functional specialization of employees. ESU Alameda’s several detachments and 
contractor shops are located throughout the Eleventh Coast Guard District. 

After the implementation of the Coast Guard Streamlining initiative (explained 
later in this chapter), ESU Alameda’s internal organization resembles that found in Figure 
3 . 3 . 
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Figure 3.3 ESU Organization, [Ref. 19]. 



4. Existing Technology 

The Coast Guard is transitioning from a proprietary computer system to a 
Windows NT 3.5 system using the Microsoft OflBce 95 software suite. ESU Alameda just 
received this new NT based computer system after using a 14 year old proprietary system 
since inception of the command. However, they are planning to upgrade to NT 4.0 and 
the office 97 suite within the timelines of this project and request intranet and database 
prototype development for the newer platforms. The use of these computer systems is 
relatively new to ESU Alameda and several small databases have been developed for 
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individual use. However, the existing databases incorporate data duplication and may not 
properly address all interest of the command at this time. The two design teams will 
examine the data used and develop new databases to properly meet the command’s 
operational requirements while preventing data duplication. 

ESU Alameda will establish a working NT 4.0 networked platform suitable for 
their organization before this prototype will be implemented onto their system by a 
separate thesis design team. Although this creates a challenge for obtaining feedback for 
graphical user interface development, this delay will not prevent the analysis of existing 
data and the correlation of such data for protot}q)e intranet specification development 
which is the primary objective of this thesis. 

5. Contributing Factors 

Between 1994 and 1998 the Coast Guard reduced their budget by $400 million 
dollars by downsizing forces by approximately 4000 billets and streamlining the 
organization. Downsizing involves drastic changes to the existing personnel staffing levels 
but does not change the mission and responsibility of any organization. For every person 
cut, another person must pick up that additional workload. This has two major impacts on 
ESU Alameda; 

♦ fewer people on the operational platforms is likely to cause more requests for 
administrative and technical types of assistance not directly associated with an 
equipment casualty. 
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♦ Many levels of technical support previously associated with the operational 
units will now be the primary responsibility of ESU Alameda. However, by 
virtue of downsizing, this responsibility will not come with the same levels of 
support personnel assigned. 

Since ESU Alameda’s billet strength did not proportionally accompany their new 
levels of responsibility, the remaining ESU personnel must now perform a much larger 
mission, with a notably smaller staff than had previously accomplished the same tasks. 

Driven by streamlining and enabled by ESU Alameda’s new computer network, an 
analysis of critical support processes will enable the design of a prototype intranet which 
could effectively mininiize the time required to perform ESU tasks. 

6. Special Requests 

Based on private discussions held with the command staff and the workers 
performing the jobs, it was decided to forego a ranking analysis of processes for Intranet 
development and rank the major concerns and challenges of the command. This list 
quickly molded itself based on controllable events, and it was decided to attack two of the 
most challenging events of the ESU. These challenges are complex and primarily exist 
because of Coast Guard streamlining, but are within the control of the command. These 
two requests are: 

1 . Analyze existing business processes and identify areas where administrative 
tasks such as leave scheduling, personnel evaluations, and communications could be 
improved. This system should push down evaluation deadlines and push up travel and 
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leave requests without requiring any wasted time tracking down paperwork from desk to 
desk, or relying on self made transcribes as reminders of critical reporting dates. 

2. Develop a business model to automate internal funding request, parts 
orders, parts updates, and enable a push down follow-up prompt to prevent human 
oversights. The system should enable any person within the command to find out the 
status of the part from initial order to delivery without requiring the assistance of another 
ESU employee. 

C. CONCLUSION 

This chapter provided an overview of Electronic System Support Unit (ESU) 
Alameda including a brief history of the unit, an overview of the command’s functional 
organization, and mission objectives. Finally, those forces extrinsically motivating the 
need for internal changes were introduced along with the command’s critical requests for 
the intranet design team. The following chapter focuses on the prototyping process using 
the prototype development model. 
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rv. THE DESIGN PROCESS 



A. INTRODUCTION 

The design of a business application usually begins as a vague concept to either 
improve an existing process or establish a means to resolve an existing conflict. This 
chapter will examine the design process by looking at two of the most widely used models, 
the waterfall model and the rapid prototyping model. Next, a review of the project scope 
and operating environment will be accomplished and compared against the strengths and 
weaknesses of these two models. Finally, the methodology used to gather data and the 
means of establishing the prototype specifications will be presented. 

B. DESIGN MODELS 

Once the need for a business application is established it can be viewed as 
transitioning through a series of developmental phases. Usually, a product is conceived 
through an individual’s idea, conceptually coming from any level within an organization. 
The idea must then compete for funding and political ranking within the organization and 
then proceed through some form of design, implementation, and maintenance phase. The 
evolution of this development could enhance or degrade the desired purpose for the 
application depending on how the design process is handled. Too little control over 
development could result in an environment where everything becomes chaotic and the 
focus for the project is lost. Too much control over development could create an 
environment where the design becomes policy driven to the point where even serious 
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design issues unsuccessfully compete against a rigid design policy. Without an effective 
design model in place, certain obstacles for success are predictable, such as; 

♦ The final project was not what the customer wanted (policy driven instead of 
problem driven) 

♦ The final project takes to long to develop and goes over budget 

♦ Specifications for functionality keep changing 

♦ The need for the project changes 

To enhance the successful development of an application, some form of 
development methodology must be employed to manage the intent of the project and the 
environment of the organization. This methodology must define the critical milestones of 
an organization, establish some form of development accountability, address the risks of 
the project in the initial planning stages, and define the variables and priorities which will 
ultimately drive the projects scheduling and features. 

Several design methodologies exist and the explicit or combined uses of any of 
them will largely be determined by the needs of both the organization and design team. 
Each design case vrill be unique and each design methodology will possess many strengths 
and weaknesses for each case. 

To better understand the potential contributions the two most popular design 
methodologies offer in the ESU Alameda Prototype development, each will be defined 
below and then compared to ESU Alameda’s situation. 
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1. The Waterfall Model 



Until the 1980’s the waterfall model was the only widely accepted life-cycle model 
[Ref 20, p. 45]. One of the primary advantages of the waterfall model is the ability to 
bring unity to projects of a very large scale; especially when involving several different 
design groups. By using detailed documentation from the point of project initiation 
through the life of the project, the various design teams are able to effectively bring 
organizational unity to the design effort. Detailed documentation also facilitates future 
maintenance actions for a developer who will add additional functionality to an application 
when the original designer is either no longer available, or simply can’t remember what 
was done. For this reason, the waterfall model is a valid candidate for use if the project is 
either very large, different groups will perform the design, or the future availability of the 
original designers are unknown and future maintenance of the application is a concern. 

The use of the waterfall model does have some drawbacks which must be 
considered. Since the waterfall model relies on accurate documentation, it is only a good 
choice for development if the customer knows exactly what they want the application to 
do and can effectively communicate those requirements in written context with the 
designer. For this reason the success of the waterfall model is heavily influenced by both 
the customer and designer having a thorough understanding of the design concept and 
needs of the organization. A diagram of the waterfall model is presented in Figure 4. 1 
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When using the waterfall model, the customer performs the first task by 
meticulously determining their business environment and defining the specific requirements 
they need from the developer’s application. Once the exact requirements are known, the 
organization must translate those requirements into a written specification stating exactly 
what the completed product will accomplish. As previously mentioned, this is one of the 
weaknesses with the waterfall model. Since the success of the entire design rests with the 
completeness of the specification, any missing, contradictory, or ambiguous wording may 
result in serious consequences ranging fi'om a loss in productivity, wasted funds, or 
changes in political standing for an organization. Even if performed properly, the rigid 
implementation of each phase combined with the verification and documentation tasks 
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often leads to extensive project management requirements, cost overruns, project delays, 
and products that fail to meet the customer’s operational requirements. 

If the developer has any difficulty associating the requirements from the 
specifications, feedback is provided to the organization. When this occurs, the 
specifications must be revised before the development can continue. This is denoted by 
the feedback arrows originating from a lower positioned box to an upper positioned box in 
Figure 4.1. An example of this would be the arrow from the Design box back to the 
Specifications box. 

As previously mentioned, the waterfall model is dynamically implemented by the 
use of feedback loops between each stage of succession to resolve any found 
discrepancies. Each stage signifies the completion of a development milestone by 
providing additional documentation to the next segment. Using this methodology, the 
waterfall model allows for revisions of specifications, design, and associated 
documentation at all stages of the of the development cycle. This iterative process helps 
ensure correct documentation exists when the project is finally complete, but can be 
extremely time consuming to perform. 

Another drawback to the waterfall methodology is the requirement for extensive 
customer testing late in the development life cycle. Since the waterfall model is a time 
intensive process there is a distinct possibility the customer’s requirements may either 
change or no longer be required before a testaWo application can be developed. 
Therefore, the waterfall model does not lend itself to continual risk assessment which may 
be a desired prerequisite of the customer. Further, if the customer fails to fially understand 
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the technical documentation produced, a perception of milestone acceptance may be 
viewed by the developer. There exists a good chance that neither side will realize the 
project fails to meet expectations until significant resources are consumed and the product 
reaches the testing milestone. Depending on the complexity of the errors, the entire 
specification and project may require rework or even termination. A means of reducing 
the time required for development and ability to obtain customer feedback earlier in the 
development life-cycle is a major reason rapid prototyping was developed. 

2. The Rapid Prototyping Model 

This application developmental approach is a systems development methodology 
created to rapidly deploy a desired application. By unifying the ideas and focusing the 
eflforts between developers and the actual users of the application, the amount of time and 
funding required to design and implement an application can be reduced. The concept 
relies heavily on customer involvement throughout the design phases where a rapidly 
developed prototype is used as an instrument to converse requirements and resolve 
misperceptions. In this concept, the prototype is defined as a working model that is 
functionally equivalent to a subset of the product [Ref 20, p. 49]. The rapid prototyping 
development process is portrayed in Figure 4.2. 
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Figure 4.2 Rapid Prototyping Model, [Ref. 20, p. 51] 



In this model the initial requirements are gathered by means of interviews, 
questionnaires, or any other means available to the analyst. The data or processes are 
examined using CASE tools and the conceptual ideas of the desired application are rapidly 
developed using any quick design tool available which is capable of rapid change. The 
analyst and end users then work together using the customers feedback to iteratively 
resolve all process and data misperceptions and gain a better understanding of the 
application’s requirements. When completed, the prototype becomes the specification for 
the actual product development. 

Using the rapid prototyping methodology enables the customer and developer to 
quickly agree on the applications functionality. When contrasted with the waterfall model, 
the need for feedback and time consuming rework between successive layers is 
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significantly reduced, making the design timeline linear instead of exponential. This is 
largely due to the fact the user is able to see errors, clarify misperceptions, and offer 
feedback at the initial development phase instead of the later implementation testing phase 
associated with the waterfall model. For this reason, the use of rapid prototyping is an 
ideal methodology for customer’s who possess any of the following traits: 

♦ Unsure what they really want 

♦ Have changing operational requirements 

♦ An initial level of risk assessment is desired before obligating for development 

♦ There exist a quick need for the application 

♦ Development is not complex and does not require several disjointed teams 

In the rapid prototype model, the completion of the specification means a 
milestone is reached where the customer has validated the functionality of the prototype 
and actual design of the application can begin. Since the functionality of the prototype is 
confirmed during the initial stages of design, the chances of an incorrect specifications are 
greatly reduced. Therefore, rapid prototyping offers a level of risk assessment for those 
organizations who are not sure if their requirements are technically feasible. 

The implementation phase of both the waterfall and rapid prototyping model often 
reveals design faults and causes additional delays. However, because the prototype 
actually tested some functionality of the application, the quantity of design faults using 
rapid prototyping could arguably be less. 
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The use of the rapid prototype methodology offers many advantages over the 
waterfall model but also adds additional challenges to the design process if improperly 
managed. One of the largest errors made in the rapid prototype development is the use of 
the original prototype for the actual application. This alternative means is usually an 
unwise developmental methodology which typically refines the prototype until it in itself 
becomes the actual application as shown in Figure 4.3. In practice, this concept does 
nothing more than waste time and money attempting to fix a product that was never 
intended to meet the operational requirements of the organization and therefore should not 
be used. 




Figure 4.3 Unwise Version of Rapid Prototyping, [Ref. 20, p. 52] 
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c. 



SCOPE 



The scope of this project encompasses the conceptual design of a baseline Intranet 
for ESU Alameda. The prototype makes every attempt to change existing business 
models by decentralizing existing tasks to the lowest possible level so as to free up critical 
command personnel. Rather than a complete system, the prototype’s primary objective is 
to evaluate existing processes and define requested specifications for ESU Alameda 
suitable for intranet development. Additional areas suitable for further development and 
evaluation will be presented in chapter five. The prototype includes the graphical design 
of the baseline intranet, administrative section, and specifications development for the 
supply tracking system. The primary objective of this team is to gain an understanding of 
existing business challenges, analyze existing processes, define ways to improve these 
processes with intranet development, define a set of specifications for ESU Alameda, and 
offer feedback assistance to another design team for the actual coding and implementation 
of the prototype intranet if required. 

To develop this prototype, CASE tools will be used to analyze the business 
processes. However, at the request of ESU Alameda, Commercial Off The Shelf (COTS) 
Software will be used to develop the conceptual design and specifications. By using 
COTS, the design remains scalable to new mission requirement and future development by 
contracted sources as deemed necessary by ESU Alameda. For this reason, existing 
Microsoft web editors, database software, and oflfice products found at ESU Alameda will 
be used by the design teams. 
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D. OPERATING ENVIRONMENT 



As previously mentioned, ESU Alameda recently upgraded from a 14 year old 
proprietary computer system to a networked architecture using Pentium based machines 
with Microsoft’s NT 3.5 operating system and the office 95 professional business suite. In 
addition, ESU Alameda is planning to upgrade to the Microsoft NT 4.0 operating system 
and the office 97 professional business suite within the next three months. ESU Alameda 
would like to use their newer software to minimize additional training required for their 
employees and therefore request all prototype applications be developed using the 
mentioned technologies. Using existing software will also enable this prototype 
development to remain scalable and capable of rapid changes by the organization to meet 
the evolving mission requirements of ESU Alameda. With the recent transition to this 
new hardware and software, a baseline system is in need of development to enhance 
communications while minimizing data duplication. 

In addition to the above technical challenges, ESU Alameda recently doubled in 
size as the result of a Coast Guard organizational streamlining program. This means that 
ESU Alameda has now absorbed several duties not previously under their control and is 
now required to perform a much larger mission, Avith a notably smaller staff than had 
previously accomplished the same tasks. Therefore, ESU Alameda requested this team 
study their current business model and identify ways their new NT based platform could 
enhance the growing organization, making it more efficient; specifically in the areas of 
administrative oversight and supply tracking. 
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E. CHOSEN METHODOLOGY 



ESU Alameda is currently experiencing rapid changes in organizational structure, 

duties, and operating guidelines as a direct result of the Coast Guard streamlining 

initiative. However, even with these business challenges, the organization continues to 

maintain an intrinsic desire to improve their support services. This motivation is largely 

due to the commands decentralized use of innovation, a concept that is clearly written 

within the Commanding OflScer’s operating instructions: 

I expect each of you to improve our system of doing business, to be 
innovative, and to think for yourselves. If a policy prevents improvement, 
or hinders service to the customer, point it out via the chain of command, 
and I wall work on it [Ref 19]. 

To meet the needs of the evolving ESU organization, it was decided to use the 
rapid prototyping methodology over the waterfall methodology for this development. 
This decision was largely justified for the following reasons; 

♦ ESU Alameda did not have the time, background, or clear idea of the needed 
functionality of the application to enable a detailed specification to be 
developed by the organization. The use of rapid prototyping alleviates them of 
this burden and instills a clearer understanding of the development task by both 
the organization and developer 

♦ ESU Alameda is evolving and susceptible to rapid changes to meet mission 
objectives. The ability to meet these potential changes is better suited to rapid 
prototyping 
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♦ Critical ESU personnel are scheduled for transfer, making feedback difficult if 
not impossible. Rapid prototyping requires the majority of the feedback 
initially and reduces the need for feedback between successive development 
stages later on 

♦ Available time of both the ESU and development team was limited to five 
months, making the rapid prototype the better choice 

As previously mentioned, in the design of the ESU Alameda Intranet prototype a 
specific methodology was employed. Coupled with a short project development timeline 
and the lack of clear specifications from the user, the waterfall method was rejected. 
Instead, the ESU Alameda prototype intranet was developed as two different sets of 
specifications; one modeling the command’s administrative issues and one modeling the 
decentralized use of data for the command’s supply tracking system. Both prototypes 
used similar rapid prototyping methodologies and obtained input fi'om all team members. 
However, the scale and complexity of the two systems did not allow the same 
specification development tools to be used. For this reason the two design teams 
unilaterally analyzed data, provided input for system functionality, and developed 
graphical interfaces. However, the development of the prototype specifications was 
separated into two separate teams*, with each team writing a separate thesis. 



* LT Ralph Benhart and LT Dean Dardis comprised the Supply Tracking System team and developed this 
thesis using Microsoft Access for the specification development tool, while LT Todd Haimah comprised 
the Persoimel Administration team and developed a separate thesis using Microsoft’s Active Server 
Scripting as the specification development tool. 
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F. DATA CAPTURING 



One of the core components in creating a successful application is the gathering of 
information. At the very start of the project the analyst must obtain an understanding of 
the existing systems in use and determine how those systems interact with the user’s 
processes. In addition to existing hardware and software constraints, the organization’s 
objectives, short and long range goals, political standing, current stakeholders, and current 
challenges must be addressed. Depending on the available time the organization and 
analyst have, one or more of the following methods could be used to obtaining this 
information; 

♦ Interviewing the users, managers, and stakeholders of the organization. This is 
thorough, but time consuming 

♦ Interview groups of users of the organization. This takes less time but may not 
reveal all the details that are required 

♦ Develop and distribute questionnaires 

♦ Obtain and analyze existing documents, forms, and operating instructions. 
This helps ensure the proper uses of data are understood and provides a means 
to develop graphical interfaces which are already familiar to the users. It 
becomes a key part of analyzing processes which will be further described in 
chapter six 

♦ Directly observe workers in action 

For this project an initial trip was made at the onset to gather data and gain an 
understanding of ESU Alameda’s business model, challenges, desires, and pohtical 
standing. Appendk A is a trip report which records the events of this trip and defines the 



54 



ways information was gathered. In short, forms and documents were gathered, structured 
group and individual interviews were conducted, and a political risk assessment for the 
project was performed by talking to all members of the organization as well as external 
stakeholders. Based on private discussions held with the command staff and the workers 
performing the jobs, it was decided to forego a ranking analysis of processes for intranet 
development and rank the major concerns and challenges of the command. This list 
quickly molded itself based on controllable events, and it was decided to attack the top 
two challenges of the ESU; the personnel administration and supply tracking systems. 
These challenges are complex, but within the control of the command. Analyzing existing 
processes and data to develop new business processes to free up the command’s limited 
personnel resources became the primary focus of this project. The analysis of this data is 
performed in chapter six. 

G. CONCLUSION 

A background of several known design methodologies was provided to the reader 
to enhance the understanding of the methodology chosen for this project. Next, a review 
of the projects scope and operating environment was accomplished to enable the reader to 
compare the development climate against the strengths and weaknesses of these two 
models. Finally, the means used to collect information for this project was presented. 
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V. CANDIDATE APPLICATIONS FOR BUSINESS SOLUTIONS 



A. INTRODUCTION 

Chapter five will address the potential functionality of the ESU Alameda intranet 
by providing a brief review on the types of applications typically used within corporate 
intranets, and then offer suggestions to modify this list for military application 
development. The majority of this chapter will then focus on the conceptual ideas for 
applications which would offer significant improvements to the current business processes 
of ESU Alameda. 

Since the primary purpose of this chapter is to present additional applications 
which ESU Alameda may desire to add to their intranet in the future, after the command 
has developed an understanding of the capabilities and maintenance requirements of their 
new system, it could be used as the conclusion to this thesis. However, it was decided to 
present the reader with this information prior to revealing the data processes of chapter six 
and specification development of chapter seven to enable a better understanding of the 
magnitude, potential interrelations, and development challenges of some the proposed 
applications. 

B. A TYPICAL REASON FOR AN INTRANET (REVISITED) 

As previously mentioned in chapter two, an organization could use intranet 
technologies in many different ways to enhance their capabilities and efficiencies. These 
ways are repeated here for clarity. 
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The Gartner Group classifies intranet proliferation and development into 
three levels. Level 1 intranets consist of low-level implementations, static 
publishing, or simply moving content on-hne. Level II intranet 
development centers around enabling core day-to-day applications for web 
use and using the intranet as a workgroup computing platform. Level III 
intranets will be characterized by a large base of web-enabled applications, 
a consoUdation of dozens of Apphcation Program Interfaces (API’s) used 
in Level II, more secure web servers, and more powerful development 
tools. Most companies spent 1996 testing intranet waters at level I. 
Mainstream organizations are expected to develop Level II intranets in 
1997 and 1998. By 1999, top organizations are expected to plateau at 
Level HI [Ref 3, pp. 80-81]. 

Before we look at specific intranet applications ESU Alameda may want to use in 
cultivating their new business model, a review of a the typical list of intranet application 
fi"om chapter two will help remind us of some possible alternatives businesses are currently 
choosing fi’om [Ref 2, pp. 8-9]. 

♦ Electronic Mail 

♦ Directories 

♦ Organization charts 

♦ Memos 

♦ Personnel manuals 

♦ Benefits information 

♦ Newsletters and publications 

♦ Systems user documentation 

♦ Training 

♦ Newsgroups 

♦ New extracts 

♦ Job postings 

♦ Sales reports 

♦ Financial reports 

Although some of the intranet applications mentioned above are applicable to 
commercial organization, they don’t fully suit the military organization. Largely in part 
because commercial organization are profit driven, usually trying to sell a product or 



♦ Customer information 

♦ Quality statistics 

♦ Vendor information 

♦ Product information 

♦ Marketing brochures, videos, 
presentations 

♦ Product development 
information and drawings 

♦ Inventory information 

♦ Network management 

♦ Asset management 

♦ Supply and component 
catalogs 
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service to whomever will pay. Where in a military command like ESU Alameda, the 
organization is budget driven with the services offered and customer base already 
established. Specializing those applications found above to mirror the functional 
requirements of a typical military support organization would more closely resemble the 
following list. 



♦ Leave, temporary duty, and 
personnel tracking 
information 

♦ Supply ordering and tracking 
information 

♦ Electronic Mail 

♦ Phone directories 

♦ Maintenance knowledge base 
and scheduling 

♦ Contact knowledge base 

♦ Organization charts 

♦ Personnel manuals 

♦ Newsletters and publications 

♦ Manuals and technical 
references 

♦ Newsgroups 

♦ Billet transfer listings 



♦ Budget, quality, and customer 
status reports 

♦ Customer information 

♦ Performance measurements 

♦ Historical Coast Guard 
information 

♦ Product information 

♦ Training documentation 
brochures, videos, 
presentations 

♦ Project information and 
drawings 

♦ Network management 

♦ Asset management 

♦ Supply and component 
catalogs 



C. A BACKGROUND ON INTRANET APPLICATIONS 

When evaluating an application for intranet development, there needs to be a clear 

understanding of how the user will interact with the application, what business processes 

the application will assist the user in performing, and which pieces of data will be involved. 

It is generally accepted that well-designed applications today have clear 
divisions between user interface, business rules, and data. This logical 
division of an application allows significant flexibility in adapting the user 
interface over time, or applying the business rules to new data sources 
[Ref 21] 
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As previously mentioned, this project will develop a specification for a baseline 
intranet for ESU Alameda. The user interface, business processes, and data used for this 
project will be analyzed and presented in chapter’s six and seven. 

One purpose for developing web-based applications is to improve user efficiency in 
locating or distributing information within an organization. The types of applications 
which can be developed to make the user more efficient are immense and only limited by 
the organizations creativity, employee computing knowledge, or available funding to 
outsource application development. The applications which can be developed by the 
organization’s employees or development firms are generally placed into one of three 
types of categories. 

1. Publishing Applications 

These applications are essentially one-to-many communication systems 
where information fi'om a department, section, or workgroup is posted and 
made available to the entire organization. Application of this nature are 
normally static, easy to implement, and often provide the most immediate 
and tangible monetary savings. These savings normally take the form of 
reduced production, printing, reproduction, and shipping costs associated 
with the paper on which the information was previously printed. 

2. Transaction Applications 

These applications are two-way interactive exchanges such as requesting or 
providing information to an organizational database. With these 
applications, the user normally queries a database and in return receives a 
dynamically populated HTML page with the results of the query. These 
applications are more difficult to produce than the publishing applications 
because they normally require some programming. These are the 
applications that empower users by enabling them to locate information on 
their own initiative. Transaction applications enhance productivity by 
removing the constraints that previously bound individuals to completing 
request forms or playing telephone-tag with the information source. 
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Information can be retrieved by the user when desired and on demand 
when distributed using an intranet. 

3. Community Applications 

These applications are many-to-many, collaborative interactions that 
facilitate the direct exchanges of information between members in a 
department, section, or workgroup. This exchange, represents the start of 
a “thread” that is available for others to review or add relevant information 
or comments. This thread would be listed in a newsgroup under a subject 
line, the authors, and an article number and would be available for others to 
investigate. Community applications are especially effective for project 
teams that are dispersed throughout a large geographic area but who must 
still communicate and coordinate their efforts in achieving an assigned 
project [Ref 22, pp. 35-36]. 

The remainder of this chapter will examine some of the possible applications ESU 
Alameda may desire to develop and implemented to add additional functionality to the 
baseline intranet described in chapters six and seven. 



D. POTENTIAL ESU ALAMEDA APPLICATIONS 

1. Administrative and Personnel Tracking System 

The tasks of planning, coordinating, verifying, and validating many of the common 
military administrative issues such as leave request, temporary duty assignments, duty 
routines, and performance appraisals can be extremely time consuming for an organization 
to perform. This is especially true for a growing organization such as ESU Alameda. An 
apphcation where common administrative tasks are performed online would prevent the 
duplicate and time consuming efforts currently associated with routing paperwork, 
verifying status, and providing continual feedback up and down the chain of command. 
To make this concept work, a client server model would be used with an administrative 
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web application. The application would automate commonly used forms and use a task 
tracking system to allow users to submit routine request such as leave and temporary duty 
paperwork from their computer browser. Since the application would allow users to input 
all routing information, the request would be automatically and immediately distributed to 
the next responsible person, thereby preventing the need for additional routing paperwork 
generation. The next individual on the list would automatically be notified a request was 
made and would be capable of jumping to a predefined web page to act on the request. 
This application offers another time saving advantage to managers and supervisors since 
they will no longer have to sift through overflowing inboxes looking for common 
documents requiring action. In this application, the manager or supervisor is presented a 
to-do list view of all forms currently in existence where their signature is required. This 
enables comparison of all open requests and enhances the decision making process. Once 
acted upon, the request is cleared from the manager’s or supervisors to-do list screen, a 
notification is given to the requestor and next individual on the routing list automatically. 
In addition, a defined web location is automatically updated which users can view to see 
the existing status. The need for time consuming status tracking and feedback up and 
down the chain of command is now completely handled by the application. The tracking 
application would offer similar functionality for performance marks. A to-do style screen 
will update key individuals automatically when performance appraisals are due or behind 
schedule. 
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2. Supply Tracking System 

A customer service oriented support organization such as ESU Alameda heavily 
relies on the processes of ordering, shipping, distributing, and tracking hundreds of supply 
parts to perform their mission. Since the lack of any one of these critical parts can 
significantly impact Coast Guard operations, an application which can track, organize, and 
provide status information to any member in the command is needed. Specifically, the 
application must decentralize the Storekeeper’s (SK) input of specialized codes, status 
tracking, and feedback to the technicians which order the parts. Since key command 
personnel are not always available and there exist a definitive need for various personnel 
to research status conditions, the application, must offer a mechanism for any member of 
the command to gain information on the status of a part. To offer accountability, the 
system must maintain the integrity of the system by archiving all data used. Based on 
interviews, use of such an application will free up over 25% of the SK’s available time and 
allow this over tasked person to be used in more specialized areas such as budget 
preparations, contracting, planning, and resolution of difficult requirements. 

3. Plan of the Day 

Publishing of the Plan-of -the-Day on web pages would enable quick access to 
current information as well recent or archived information that may be desired fi’om 
personnel returning from temporary travel. Employees and Coast Guard Reserve 
components would be able to access this information at any time of the day fi’om either 
work or home. This could be modified to include specialized information for Coast Guard 
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Reserve forces to enhance communications on upcoming training, unifomi requirements, 
drills, and mustering locations. 

4. Command Phone Book and Email Listing 

This application would prevent the current “paper” phonebook from requiring 
continual publication and distribution to remain current. Using web pages and search 
engine technologies associated with many of the web products in use would enable users 
to search for a specific person by name or duty section. Before this type of application is 
implemented, the command must generate policy for the type of data to display and 
maintenance of it’s accuracy. To prevent data duplication, this application should obtain 
its data from the administrative areas of the intranet, which will most likely be associated 
with a database. This way,- personal data on employees is updated within the 
administrative area and phone book at the same time. Since the administrative database 
will most likely contain private information that the crewmember does not want 
publicized, the command must determine what information will be published for intranet 
access. An even more refined listing may be desired for extranet customers if the 
command would like to make the phone listing available to the other agencies. A good 
addition to the search tool in this application would be to use hypertext formatting for 
email hstings. This way a user could quickly generate email to the selected person by 
merely clicking on the hypertext name of the person in the email section of the phone 
listing. 
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5. Maintenance Knowledge Base and Scheduling 

Although very useful, the maintenance of this type of application would need to 
come from an organization external to ESU Alameda, and is therefore outside ESU 
Alameda’s control. Since the maintenance procedures and servicing schedules are 
established by Coast Guard Headquarters personnel, the design and maintenance of this 
application would be best suited for headquarters development and distribution. 
Development by ESU Alameda would require continual application modifications to keep 
pace with headquarters changes, making the benefits not worth the costs to implement. 
Assuming the application was established by headquarters and installed, an ESU Alameda 
technician could type in questions to aid in the resolution of difficult electronic repairs or 
to gain information for servicing procedures. A system to help technicians schedule and 
log preventive maintenance routines would also be useful. If linked to a headquarters 
intranet application, maintenance data could automatically be tabulated and measured 
against equipment failures, supply levels, and mean time between repairs to forecast 
mission impact and budgetary requirements. 

6. Contact Knowledge Base 

Coupled with the large turnover rates associated with military transfers, unique 
operational requirements, and ESU Alameda’s extensive need to collaborate with 
multitudes of organizations, some form of knowledge base needs to exist to help newer 
personnel locate key organizations and personnel. Since the electronics funding, 
equipment, and repair parts used by the Coast Guard originate from numerous Coast 
Guard and Department of Defense organizations and personnel, deciding where to go 
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when equipment fails can be extremely challenging. This is especially for newly assigned 
personnel. Currently, experience is used to link specific equipment to specific people and 
specific organizations. But this information takes time to learn and is regularly outdated, 
forgotten, or misplaced. Even when the correct information is located, large amounts of 
research duplication is conducted within the ESU command because the technology does 
not exist to enable collaboration. However, with the installation of the intranet a Contact 
Knowledge Base application can be used to share information, reduce research times, and 
enable easier updates to modifications. This type of application will work similar to a web 
search engine and the unit phone book. A user can use search engine technology within 
the application to type in equipment nomenclatures, titles, or any other information known 
to track a specific piece of equipment to produce a listing of all matching resources. The 
listing will then provide a detailed summary of the organization and person associated with 
that piece of equipment and how they relate to ESU Alameda. The user then matches 
their current operational need against the list of resources until a match is found. The list 
can be shared and maintained by everyone using it, so as changes occur, they only need to 
be updated once to make it beneficial to the entire command. The use of the application 
will continually evolve as people enter more and more information into the system. This 
type of application will help reduce the time required to bring new personnel up to speed 
and minimize the command p^ns associated with loosing 25% of the crew each summer 
during the annual transfer season. 
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7. Operating Instructions, Personnel Manuals, Newsletters, and 
Orientations 

The use of web based personnel manuals, operating instructions, newsletters, 
organizational charts and orientations will enable personnel to quickly become acclimated 
with command procedures. Orientations on command history, operating procedures, and 
accomplishments can be used to mold the new personnel into the desired culture of the 
command. As mission goals change, this application will enable the quick modifications to 
business policies. In addition, the use of a web-based application will help mold mental 
models and instill group learning as organizational changes are required by using media 
which is more impacting than written text alone. Currently over 100 manuals are 
published and distributed biannually to organizations supported by ESU Alameda to offer 
guidance and procedures. However, ESU Alameda has no guarantee that the current 
versions of these manuals are made available to the key members ESU Alameda interacts 
Avith. This creates a burden for both ESU Alameda and the key members of the supported 
commands. By using a web-based application, every individual with a computer and 
intranet/extranet access will be able to interact with the most current ESU publications 
available. Therefore, not only will this application enhance the learning environment of the 
ESU employees, but it will also enable better distribution, reductions in biannual 
publishing and distribution fees, and access to current information by those commands 
supported by ESU Alameda. 
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8. Newsgroups 

The use of a newsgroup application by the ESU employees would enable them to 
solicit information and keep abreast of technology changes with the rest of the world. In 
addition, internal newsgroups could be established and made available to employees or 
other Coast Guard organizations. Since any post to a newsgroup outside the organization 
will have a military extension on it, strict command policy must be implemented governing 
the types of groups which are accessible and the extent of information which will be 
exchanged. Since the use of internal newsgroups are proprietary, the security aspects are 
much less complex and easier to implement and enforce. For this reason, ESU Alameda 
may want to only use internal newsgroups, or restrict access to these groups to only 
selected Coast Guard Commands. 

9. Customer Knowledge Base 

Coupled with the large turnover rates associated with military transfers, unique 
operational requirements, and ESU Alameda’s extensive need to collaborate with 
multitudes of organizations, some form of knowledge base needs to exist to help personnel 
locate technical information about supported commands. For example, a typical ESU 
supports several classes of ships, each with different equipment and different engineering 
parameters. Some of these organizations have unique challenges such as electronic power 
or grounding problems, cable access challenges, or antenna location constraints to name a 
few. This makes it difficult for any remote personnel to plan future installations, forecast 
engineering challenges, or simply offer technical assistance since each class of ship is so 
unique. However the use of a customer knowledge based application would enable a user 
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to search out needed information on a specific Coast Guard unit, and receive details such 
as wiring diagrams, photographs, known problems, archived repairs, and past engineering 
studies. In addition, existing fault parameters could be input to the application and 
assistance provided on probable causes. However, the development and maintenance of 
such an application would be enormous and beyond the capabilities of ESU Alameda. 
Nevertheless, it would be of immense help and could be linked to a headquarters 
application to enable additional engineering and maintenance research. 

10. Military Transfer Knowledge Base 

With the average ESU member transferring every three to four years, an 
application to assist personnel plan for these moves would benefit morale and reduce the 
current planning time required by Coast Guard families. Currently, manuals are published 
listing all billets in the Coast Guard, however, these manuals become outdated the minute 
they are published. To inform Coast Guard personnel which billets are to be vacated and 
made available for selection. Coast Guard members can have information sent to them by 
means of a multiple page facsimile. However, these sheets are often difficult to read and 
offer little insight into the requirements of the job and offerings of the community. 

Development and maintenance of a web-based application by Coast Guard 
Headquarters and used within the ESU Alameda intranet would allow access to current 
billet descriptions, rotation dates, phone numbers, and skill requirements, as well as 
community information, housing, schools, and points of interest. To accommodate special 
family needs such as medical or school challenges, a knowledge based application would 
interact with the user to locate possible openings which meet those specified requirements. 
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This type of application would mirror with current Coast Guard Work-Life initiatives, 
reduce stress levels associated with moving, increase morale, and reduce some of the time 
management challenges currently plaguing program managers in negotiating possible 
transfers with Coast Guard members. 

1 1 . Customer Request, Measurement, and Report Generation 

Currently ESU Alameda customers request assistance through means of radio 
broadcast message traffic, phone calls, personal visits, or email. To conform to Coast 
Guard measurement guidelines as well as focusing on command effectiveness, designated 
ESU employees track and measure open requests, contracted performance, and funding 
information for compilation and generation of monthly reports. Since there are no ESU 
billets authorized for this function, these tasks are assigned as collateral duties to several 
ESU employees. Although this provides many positive aspects for the command it also 
reduces the available time of the technicians and crew. For this reason the available time 
for workloads is more reactive to equipment failures than proactive in preventive 
maintenance and planning. A web based application would automate some of these tasks 
and enable ESU employees to better utilize their available time. In addition, online 
generation of these reports would reduce the costs associated with publishing and 
distribution and enable real-time feedback to organizations needing this information. 
Additional functionality could be added to this application by linking it with the supply 
tracking system. Coupled together, these two applications could build a knowledge base 
capable of forecasting and graphing workloads, budget requirements, and supply ordering 
requirements for each supported platform on a calendar basis. Such a system would 
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significantly aide the organization in scheduling future projects, leave request, quarterly 
budget distributions, and just in time training requirements. 

12. Training 

ESU Alameda currently performs several types of specialized training for such 
things as new personnel indoctrination, new application familiarization, or to establish 
specialized skills for an upcoming project. To facilitate this training and enable just in time 
learning, a web-based application could be established and interactively used as needed. 
This application could be requested by the needing user anytime, therefore eliminating 
existing scheduling conflicts between the trainer and trainees. Using brochures, video, and 
internally generated PowerPoint presentations, almost any type of training presentation 
could be accomplished. If hands-on training is required, the development of a training 
kiosk may offer more interaction with the training platform. Although some specialized 
training may require professional development, many of the training tasks associated with 
annual certification and project preparations could be developed by ESU Alameda. 

E. CONCLUSION 

This chapter addressed the potential functionality of the ESU Alameda intranet by 
providing a brief review on the types of applications typically used within corporate 
intranets, and offering suggestions for military application development. The majority of 
the chapter focused on applications which would offer significant improvements to the 
current business processes of ESU Alameda. 
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Now that the reader can visualize the complexity of the various apphcations that 
would make up an ideal ESU intranet system, the design of the baseline intranet focusing 
on administrative issues and data analysis of the supply tracking system will be presented 
in the next chapter. ESU Alameda may wish to review chapter five as time goes on to 
consider future development considerations above that presented in the next two chapters. 
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VI. ANALYSIS OF CLIENT’S BUSINESS PROCESSES 



A. INTRODUCTION 

Since Data Flow Diagrams (DFDs) are one of the most widely used tools for 
modeling business processes, they will be used within this thesis to analyze the functional 
activities of ESU Alameda. To enable the reader to follow this analysis, the chapter will 
start with a brief history on database functionality. Followed by an overview of DFD 
symbols and implied rules. After presenting the required background material, the 
remainder of the chapter will present the DFDs derived for the ESU Alameda Business 
model, offering insight to current business practices and enabling a visionary look at what 
post intranet implementation may achieve. 

B. HISTORY 

Databases are categorized by the way they maintain data relationships [Ref 23, 
p. 15]. Early databases were nothing more than flat file systems that allowed a user to 
archive information and serve as electronic filing cabinets. Due to the very nature of this 
type of database, it typically led to data redundancy, which is the saving of redundant 
information on different databases. As a result of data redundancy, the data itself becomes 
diflScult to maintain and is usually inaccurate in at least one of the databases used. 
However, since the 1960's major changes in database design have been made to help 
correct this problem. 

The 1980's brought about the use of relational databases which significantly 
improved the management of data, reducing data redundancy. Data stored in one table 
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could now update many other tables or databases through shared resources. In addition, 
access to these tables could now cross several types of database platforms. For example, 
Microsoft Access could now read and write to a database written in dBase or Paradox. 
For database users this was a revolutionary accomplishment because developers were now 
able to use data already located in various databases rather than recreating the data 
themselves. Figure 6.1 offers a good overview of the features and technological changes 
that have occurred in database design. 
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1990’s 




Data Storage 



Data Storage 
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Data Storage 
Data Relationships 
Easy Data Access 

Data Storage 
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Behavior Storage 



Figure 6.1 Evolution of Database Architectures, [Ref. 23, p. 16] 
C. PROCESS MODELING 



Process Modeling is used by designers to gain an understanding of what is 
occurring within an organization. By using such a graphical interpretation of the 
processes involved an organization’s business model can be understood. 
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An effective diagram has two primary functions: it records and 
communicates. The effectiveness of a diagram is contingent on its clarity 
and completeness. No matter how accurate a diagram is, if the information 
it contains is not easily understood by its user, it is practically useless 
[Ref 24, p. 1]. 

This concept is the basis for the development and use of Data Flow Diagrams 
(DFDs). Therefore, DFDs are primarily used to clarify information flow within 
organizations, to locate redundancies, and to determine the requirements of the 
organization. Although there are several different modeling tools available, the 

advantages with using DFDs, is that there is only one set of rules and only four symbols 
used to represent the data flow. Figure 6.2 will enable the reader to translate the 



associative meaning of the two common DFD symbol sets currently in use; 



DeMarco and Yourdan 



Gane & Sarson 
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Data Flow 



Figure 6.2 

Comparison of DeMarco and Yourdan and Gane & Sarson DFD symbol sets, 

[Ref. 25, p. 3151 
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Regardless which DFD symbol set is used, a defined and common set of rules are 
used to add meaning to the analysis. Since these rules are implied, the reader must 
understand them before reviewing the ESU Alameda DFDs if proper analysis is to be 
interpreted. For this reason, a brief explanation for the use of the four symbols will be 
presented, and then followed by the rules associated with their use. A description of the 
four symbols represent in a DFD are as follows: 

1. Process: The work or actions performed on data so that they are 
transformed, stored, or distributed. 

2. Data Store: Data at rest, which may take the form of many different 
physical representations (i.e. a file folder, notebook). 

3. Source/sink: The origin and/or destination of data sometimes referred 
to as external entities. 

4. Data flow: Shows the direction that data is flowing through a system 
[Ref 25, p. 315]. 

As previously mentioned, the use of DFDs is simplified by the small symbol set and 
single set of implied rules. This feature enables analyst to share their DFDs with many 
different designers without the need of written details. Just like the phrase “a picture is 
worth a thousand words” the DFDs tell the story which may otherwise be misinterpreted 
in written context. To enable the reader to understand the ESU Alameda DFDs which will 
be presented later in this chapter, the DFD rules will be presented in an easy to access 
format suitable for quick reference later on. These rules are as follows: 

Entities 

♦ Relationships between Entities are not modeled 

♦ Entities never communicate directly with data stores 
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♦ Entities are always named using a noun label 

♦ Changes to Entities can only occur through data interchange with the Main 
Process. 

Processes; 

♦ Processes are always named in a verb phrase label 

♦ Processes may be done in parallel 

When working with Processes, you should avoid the following; 

♦ Black Holes: A process with only inputs. See Figure 6.3 



Various 



Input 




Figure 6.3 Black Hole 



♦ Miracles: A process with no inputs and only outputs. See Figure 6.4 
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Figure 6.4 Miracle 
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♦ Grey Hole: Insufficient inputs to produce the outputs. See Figure 6.5 
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Figure 6.5 Grey Hole 



Data Store: 

♦ Data cannot be interchanged between other data stores. The data must pass 
through a process initially 

♦ Data Stores do not change (process) any data 

♦ Processes are always named using a noun label 

♦ Data Stores may be repeated on a diagram 
Data Flow: 

♦ Data flows are drawn in one direction between processes. If data is Bi- 
directional, two data flows must be drawn. 

♦ A Data flow to a Data Store means Update 

♦ Data flow from a Data Store means Retrieve 

♦ Processes are always named using a noun label 

DFDs are hierarchical by design. By this we mean the Context Level diagram is 
the parent and is the highest level diagram possible, showing the an entire organization as 
one process. When viewing this diagram, the user will be able to see those entities 
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external to the organization that interact with the main process by the transfer of 
information. Decomposition of the Context Level diagram is used to obtain child, or 
lower level DFDs. When doing this, the decomposition of the Context Level diagram 
leads to a Level 0 diagrams with a numbering convention of 1.0, 2.0, 3.0...X.0. Further 
decomposition of these processes lead to Level 1 diagrams that follow the numbering 
convention of 1.1, 2.1, 3.1 ...x.l. This decomposition of a processes can continue until 
the primitive, or lowest level DFD is obtained. When looking at the entire numbering 
convention used, t}^ical numbers for lower level diagrams could be as follows; 1.1.1, 
1.1.2, etc. 

Balancing DFDs is essential for accuracy and is defined as the conservation of 
inputs and outputs to a data flow diagram process when the process is decomposed to a 
lower level [Ref 25, p. 324]. This means that as the diagrams are further decomposed the 
input and outputs associated with a given process must be accounted for throughout the 
Child and Parent relationships. 

D. ANALYSIS PHASE USING DATA FLOW DIAGRAMS 

As previously mentioned in chapter four, data was gathered from ESU Alameda by 
obtaining various forms and publications as well as conducting individual and group 
interviews. During the interviewing process the functionality of various forms was 
determined and compared against the business models of the organization. Of all the 
forms collected, it was determined that four actually applied to the business model this 
team was asked to improve and therefore analyzed for intranet implementation. These 
forms included the supply Procurement Request form. Bill of Lading form. Requisition 
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Log (SURF Sheet), and the administrative standard Leave Request form. In addition, the 
team decided to include additional administrative data on the intranet because of its related 
use and similarity of development. This data includes the Command Phone Book, 
Temporary Additional Duty (TAD) log, and crewmember directories. 

To accommodate all of this information without sacrificing security the intranet 
was developed in two sections. The secure section was termed the intranet, while the less 
secured area was termed extranet. 

A full service Intranet is a TCP/IP network inside a company that links the 
people and information in a way that makes people more productive, 
information more accessible, and navigation through all the resources and 
applications more seamless than ever before [Ref 23, p. 57]. 

The extranet provides some of the same information as the intranet but is not 

subject to all of the security and privacy aspects desired in a corporate intranet. Without 

an additional security measure such as a firewall, the extranet is accessible to anyone who 

has access to the internet and the correct Uniform Resource Locator (URL) or internet 

address. 

Throughout the analysis of data, emphasis was placed on redesigning the business 
process and not simply automating it. By simplifying these transactions with the use of 
DFDs, redundancy was identified and data integrity increased. Although we’ve explained 
data redundancy, we need to examine data integrity. Data Integrity refers to the ability of 
the distributed database to manage concurrent updates to data in many physical locations 
and ensure that all of the data is physically and logically correct [Ref 26]. Therefore, by 
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reducing data redundancy and increasing data integrity the overall accuracy of the system 
will increase. 

Many simple administrative tasks such as filling out a Leave Request or Parts 
Ordering require many steps and man-hours to route paperwork through an inefficient 
system. Therefore, one of the goals of this thesis will be to reduce the time and effort 
involved in completing a task. 

This remainder of this chapter presents the DFDs developed for both current and 
new business processes selected for intranet application. The applications that were not 
used on the intranet but were evaluated at length are included in Appendix B. Detailed 
explanations of the process interactions within the current business model are included in 
Appendix C. 

1. Existing Business Models 

Figure 6.6 shows the current business model for the Leave Request process. A 
person requests leave through the process and gains approval from immediate supervisors. 
Upon approving/disapproving the leave request the form is routed to the Executive Officer 
who provides final approval/disapproval for the requested leave. 

The Leave Request process is further decomposed in Figure 6.7. Here the leave 
request is filled out and the leave form is routed from supervisor to supervisor. Upon final 
approval/disapproval the request form is sent back to the originator. 
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Figure 6.6 Context Level DFD - Leave Request 
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Figure 6.7 Level 1 DFD - Leave Request 

Figure 6.8 presents a good example of how a process was automated without 
adding any functionahty to the system. Even though the leave form is input into an 
automated system, by email, the status updates and retrieval of archived information is 
performed manually and may actually take more time to perform than the previous paper 
method. For example, when the paper version was filed there existed a filing scheme. 
With the use of email, the location and sequence of a request is unknown and could be 
located in several different locations. 
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Figure 6,8 Level 1 DFD - Leave Request 
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Figure 6.9 presents the Context Level diagram for the current Parts Ordering 
System. The function of the Parts Ordering process is to act as focal point for all of the 
command's part requests, including budget verification, quality control, ordering, tracking 
forecasting, and transportation of materials. This process is the cornerstone to making 
the command operate efficiently and is the number one request of the command to attempt 
to resolve inefficiencies within the system. 




Figure 6.9 Context Level Diagram - Parts Ordering 
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The Parts Ordering System is further decomposed in Figure 6.10. As can be seen 
in this data flow diagram, the ordering a single part becomes a very complex and time 
consuming evolution. There is a minimum of eight different processes that the requested 
part must go through before it can be completed. Delays are introduced by the processes 
themselves as well as the way information is passed. In this case, most paperwork must be 
physically "walked" to the next process. 

Since ESU Alameda heavily relies on the timely processing of parts request to 
repair electronics equipment, a means to make this system more efficient is clearly in need. 
In addition, the Storekeeper is currently overworked, spending more than 25% of the 
average day tracking down the various stages of these processes. Therefore, developing 
an intranet based system capable of improving the existing business model will have 
notable impact for all members of the command, a feature which is needed to enable the 
successful acceptance of the intranet and new business model. Because this resolution of 
this process is requested by the command and is determined to benefit every user of the 
organization, deriving a better business model became one of the top objectives of this 
project. 
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Figure 6.10 Level O DFD - Parts Ordering System 
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2. Intranet Based Business Models 



Figure 6.11 through 6.19 presents the redesigned business models enabled by the 
ESU Alameda intranet. These new processes allow a one-stop location to accomplish in 
minutes or hours what used to take hours, days, or even weeks to accomplish. The 
intranet based design depicts a well thought out approach that is extremely user friendly. 

It is the intent of the design team to reduce the required work efforts and times by 
centralizing all of the Administrative and Supply tools in one location. As can be seen in 
Figure 6.11, there is a central point for users to enter the intranet to accomplish these 
tasks. 
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Figure 6.11 Context Level DFD - ESU Intranet Processes 

Once the user enters the main interface, the user has the choice to access the 
Member or Public sections as portrayed in Figure 6. 12. To enter the Public area the user 
simply selects the extranet. There is no requirement to log into an unsecured area. To 
access the intranet all users must login with an authorized user name and password. Upon 
successful login the user enters the Member's area where secure information is kept. If the 
log in is unsuccessful they are returned to the main screen. 
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Figure 6.12 Level O DFD - ESU Intranet Processes 



Decomposing Process 4 to the next level allows access to limited resources on the 
extranet as shown in Figure 6.13. At this level there is access to multiple resources, such 
as FAQ's, what’s new on the intranet, and access to the unit phonebook. Process 4.2 
allows access to the unit phonebook. 
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Figure 6.13 Level 1 DFD - Select Extranet Application 



Process 4.1 is further decomposed in Figure 6.14. Within this process, process 



4.3.4 enables additional menus options to the user such as Suggestions, Chat Room, and 



intranet wide search capabilities. 
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Figure 6,14 Level 2 DFD - Query Help Section 



Process 3.1 is the Level 1 DFD for Process 3 of Figure 6.12. This Process allows 
the option of entering the Supply or Administrative areas of the intranet. 
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Figure 6,15 Level 1 DFD - Select Intranet Application 
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Figure 6.16 reveals the Processes that encompass the Supply Section of the 
intranet. Process 3.3.2 allows any of three forms to be filled out online, read the database 
warning, or exit to the main menu. Screen shots of the four forms will be provided in 
chapter 7. 
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Figure 6.16 Level 2 DFD - Select Supply Applications 
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Figure 6.17 presents the processes that encompass the Administrative Section of 
the intranet. Process 3.2.2 allows access to either Administrative Reports or 
Administrative Forms. 
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Figure 6.17 Level 2 DFD - Select Administrative Applications 



Figure 6.18 allows the user to view any of four reports online. These are dynamic 
reports and are enabled through the processes in Figure 6. 19. Reports are also available at 
demarcations of thirty and sixty days prior to going TAD or on leave. This information is 
essential for command planning purposes and relinquishes time spent by managers and 
supervisors in tracking this information. 
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Figure 6.18 Level 3 DFD - Select Administrative Reports 



Figure 6.19 allows users to select online forms. In this Data Flow Diagram, 
Process 3. 2.3.2 enables the person who filled out a leave request to monitor its status 
without requiring time consuming research of supervisors and managers. As the leave 
request advances through the system, annotations approving or disapproving the request 
will be added. This allows for instant response and monitoring. In similar fashion. 
Process 3. 2. 3. 3 allows the user to request TAD orders online. Both of these processes are 
capable of being updated at anytime. Leave or TAD requests are archived for future use 
to allow for historical tracking. 
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Figure 6.19 Level 3 DFD - Select Administrative Reports 



The complexity of the new business model is overshadowed by the ease of access 
to all information. The use of the DFDs presented in this section illustrate that ESU 
business processes can be changed and improved. For this case, change is not made for 
the sake of change, but as an effective tool in obliterating old business practices to 
improve efficiency and command productivity. 

The CASE tool used to design the DFDs for this thesis was Visible Analysts 
Workbench Student Edition^ Version 6.0a. The symbol set used in the design of the 
DFD’s was Gane & Sarson. The DFD’s were decomposed to their lowest level and 
balanced. 
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E. CONCLUSION 



This chapter provided a brief history of the database evolution and the knowledge 
required to understand data flow diagrams. The diagrams included within this chapter 
depicted a transition from individual processes under the current business model to a fully 
integrated intranet based process utilizing the business model developed as part of this 
thesis. Security aspects of the intranet were briefly described and will be presented in 
more detail in chapter 8, the conclusion of this thesis. As a reminder, all additional DFDs 
for processes not incorporated into the intranet are provided in Appendix B for future 
development considerations. 
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Vn. BVTRANET DESIGN 



A. INTRODUCTION 

This chapter will explain the importance of the graphical user interface and 
present various screenshots for the ESU Alameda intranet design specification. It will 
explain how the use of iterative database designs enabled a development that met the 
business models established in chapter six. Several screen shots are included to enable 
the reader to understand the uses of this rapid prototype development effort. 

B. INTERFACE DESIGN 

To this point the readers have been introduced to several potential intranet 
applications (chapter five), as well as analysis of pre and post intranet business models 
(chapter six). However, it should be understood that these applications would not enable 
the success of the proposed business models without the use of a well-defined graphical 
interface. For without the use of an interface that is easily navigated and intuitively 
understood, the users will reject the intranet concept and the new business model would 
fail. Therefore, the conceptual design of a robust graphical user interface became another 
primary design consideration for this project. 

In defining the interface requirements and humanistic feel for the ESU Alameda 
intranet, the team evaluated several web sites known to distribute information. After 
researching several possibilities, the team was inspired through use of a proven 
commercial web site at http://mv.excite.com. and decided to use this philosophy to pass 
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daily information within the ESU Alameda intranet. The team then placed emphasis in 
designing a user-friendly interface that maintained the following attributes: 

♦ Utilizes a point and click interface 

♦ Provided timely and informative information 

♦ Consistent "Home Page" look and feel 

♦ Speed when loading pages 

♦ Simplicity and familiarity when navigating 

This concept was achieved by starting all users on the intranet "home page" when 
they initially logged onto the intranet. At this location, the user is able to quickly assess 
the operational state of the command by merely glancing the descriptive hypertext titles 
on the screen. If detailed information were desired, it would be obtained by clicking on 
title. By composing the descriptive titles onto one page and forcing the users to start at 
this location, the command is guaranteed all users are exposed to the command’s critical 
information each time the intranet is accessed. 

The consistent look of the intranet was achieved by displaying the left frame at all 
times. This is made possible during the initial download of the intranet site where the left 
frame is stored in cache memory. By maintaining a consistent left frame, both download 
speed, simplicity, and familiarity are achieved. The consistent left frame also allows the 
user to select alternate applications within the intranet at any time. The right frame will 
display the newly selected information. This can be seen later in this chapter as various 
online forms are displayed where the left frame is static and the right frame is dynamic. 
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C. INTRANET SOLUTIONS 



By analyzing the new business models in chapter six, along with some of the 
ideas used at http://mv.excite.com web site, a baseline for the intranet’s design can be 
seen. For example, the Data Flow Diagram in Figure 6.11 enabled the old business 
process to be transformed into the opening screen shot for the Intranet in Figure 7. 1 . This 
enabled the command at ESU Alameda to be able to retrieve important statistical facts at 
a moment's notice. This would create a new way of doing business, as the information 
would be virtually real time. Items of interest provided on the opening screen of the 
Intranet are: 

♦ General announcements 

♦ Leave Summary 

♦ Personnel on Temporary Additional Duty (TAD) 

♦ Plan of the Week 

As mentioned in chapter 4, this project was developed conjointly as a three- 
member teaml. This chapter highlights the Intranet solution with the emphasis being 
placed on the database solutions. 



' LT Ralph Benhart and LT Dean Dardis comprised the Supply Tracking System team and developed this 
thesis using Microsoft Access for the specification development tool, while LT Todd Hannah comprised 
the Personnel Administration team and developed a separate thesis using Microsoft’s Active Ser%er 
Scripting as the specification development tool. 
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Electronic Support Unit Alameda Intranet 
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Figure 7.1 Intranet Opening Screen 
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To facilitate the use of the new supply and personnel tracking systems where 
responsibilities are pushed to the lowest level, several familiar forms must be introduced 
on the intranet. However, unlike the use of the old paper forms which required a large 
amount of Storekeeper or Administrative involvement, the new automated forms with 
pull down combination boxes will enable responsibilities to be pushed to the lowest level 
in the command. The required forms are as follows: 

♦ Supply Procurement Request form 

♦ Bill of Lading form 

♦ Requisition Log (SURF Sheet), 

♦ Leave Request form. 

Figure 7.2 presents the online Leave Request form. By enabling the 
crewmembers of ESU Alameda to fill out Leave Request online, not only the member, 
but also the command is able to keep track of all personnel requesting leave. This leave 
form provides a central location to monitor the status of a request. This application 
abolishes the old slow and an ineffective practice of updating and tracking leave status 
and replaces it with an automatic and very efficient central repository. 

This new form will aid in the tracking of leave requests as well as planning for 
future duty assignments at the unit. As the leave is submitted up the chain of command 
and approved or disapproved, emails are automatically forwarded to the person 
requesting the leave. This provides real time notification as to the status of the original 
request. 
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Electronic Support Unit Alameda Intranet 
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Figure 7.2 -Online Leave Request Form 



If the user selected the Procurement Request form on the main page. Figure 7.1, 
the online Procurement Request form is displayed as shown in Figure 7.3. Utilizing this 
form a member can order a part online and maintain tracking until the part is delivered to 
its destination. Once the required data is filled out in Figure 7.3, the user mouse clicks on 
the "submit" bar at the bottom of the screen to enter the description of items that need to 
be ordered. 
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Figure 7.3 - Online Procurement Request Form 
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Figure 7.4 presents the online form for requesting supply parts that need to be 
ordered. If more than five items need to be ordered at one time additional forms may be 
pulled up from this screen. 
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Figure 7.4 - Online Procurement Request Data Description Form 



As previously mentioned the left frame remains consistent throughout each form 
allowing the user to access other areas of the Intranet as desired. Figure 7.4 portrays this 
logic. 

D. DATABASE 

Although the tables used within the developed databases is part of the prototype 
intranet, the designed forms, quires and reports are not. In this case, these forms, queries. 



104 





and reports were used to test the proposed business process, ensure the functional use of 
the data was correct, and define the specifications for active server scripting by another 
thesis team working conjointly on this project. In addition, the database itself can be 
used to retrieve critical supply tracking data in the event the intranet fails to operate, 
offering a redundant system. 

This section will illustrate the design of the Procurement Request (PR) form with 
the remaining Supply Tracking System forms placed in Appendix D. The screen shots 
that are presented are from forms created in Microsoft's Access 97. 

Since the database tables are an integral part of the intranet, any unauthorized 
modifications to these tables could result in the failure of the intranet itself For this 
reason, advanced features are used within Access 97 to hide the tables from the user. 
This does not however prevent the user from using the database as a redundant system. 
When a user attempt to load the database using Access 97 the first thing they will see is 
the opening disclaimer shovm in Figure 7.5. 




. Figure 7.5 - Database Disclaimer 
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Once the disclaimer has been read the user clicks on the Continue button to access 



the ESU Alameda Supply Tracking System. Figure 7.6 offers the user the choice of 
continuing on to the Forms and Status Updates, read the disclaimer again, or exit the 
database. 




Figure 7.6 - Database Main Menu 

Entering the Forms and Status Updates area the user is again provided with the 
four menu options. Figure 7.7 reveals the user’s options. 

The detail built into each of the following forms offers the ability to automatically 
receive tracking updates, search archived information, obtain status updates, and 
decentralize tracking responsibility to the lowest level. Embedding this functionality into 
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the look and feel of existing paper forms reduces the amount of training required and 
enhances the acceptance of the intranet as a business tool. 




Figure 7.7 - Forms and Status Update Menu 



Figure 7,8 shows the Procurement Request (PR) form. The PR number in the 
upper right hand comer of the form uniquely identifies each form. The parts ordered on 
each form could be tracked and/or changed based in this number. 

Extensive use of drop-down boxes enabled the use of a knowledge base where 
users selected known information to input specialized supply codes which historically 
required extensive Storekeeper time to look up. In addition, the use of default values 
decreased the amount of time required to fill in recurring or look up unknown 
information. As shown in Figure 7,8, block 6 is a defaulted value. This default 
Command information will always be the same for Purchase Orders (PR's) originating 
from ESU Alameda Many other blocks such as blocks 1, 2, and 5 contain drop-down 
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boxes with names and information for the authorized individual at the unit. This was to 



ensure accuracy of the data and reduce the time required in filling out the form. 
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Figure 7.8 - Database Procurement Request Form 



108 




E. DATABASE UPDATE AND MAINTENANCE OF FORMS 



Information provided within the database’s drop-down boxes is dynamically 
changing as a result of such things as military transfers and changes in duty assignments. 
For these reasons, the design team added update functionality to the database to enable 
the user to quickly and easily update these forms with current information. Since each 
field in each form is associated with an update form, the user always has the ability to 
update missing or incorrect information quickly. To update the data in any drop-down 
box, all the user has to do is double-click the incorrect field with the left mouse button to 
bring up the needed form. Figure 7.9 shows such a form, in this case the unit of issue for 
parts would be used to add the “BG” symbol for bag. 




Figure 7.9 - Unit Of Issue Lookup Table Update Form 
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If a field already contains information in it, such as a default address, and a need 
exists to input different data, the user can enter the required data directly into the 
corresponding area. If the user attempts to call an update form by double clicking in the 
field utilizing the default value, the user will be told to input the data directly as shown in 
Figure 7.10, 



Microsoft Access 




Figure 7.10 - Default Data Feedback 



F. STATUS LOG 



As previously mentioned, tracking the status of each part and providing updates to 
various crewmembers required over 25% of the Storekeepers time. It is primarily 
because the SK was the only person tracking the parts and continually repeating updates 
up and down the chain of command Under the new business model, the responsibility to 
update parts falls to the division ordering the part. As updates are performed, they are 
now tracked through the use of a Status Log, a system that did not exist under the old 
business model. Figure 7.11 shows the Bill Of Lading Status Check form This from is 
typical and used in the same way for the various types of supply forms. Each time a user 
obtains new information on a supply item, they will share this information with everyone 
in the command by logging it onto this form. By using this methodology. The database 
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will maintain current information as to when the part was originally ordered, shipped, and 
any incidental information received on the part before it arrives. Anyone seeking 
information on this part can access the log and review the part history without requiring 
the assistance of another person, which has historically been the Storekeeper. The log is 
closed out upon arrival of the part by placing a check mark in the received box on the 
form. To maintain accuracy and accountability of all input data, the user's name is 
entered each time a status update is accomplished. 




Figure 7.11 - Bill Of Lading Status Log Update Form 
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G. CONCLUSION 



This chapter explained the importance of the graphical user interface and 
presented various screenshots of the ESU Alameda intranet design specification. It 
explained how the use of database designs enabled a development that met the business 
models established in chapter six and offered several screen shots to assist the reader in 
understanding the uses of this rapid prototype development effort. Although not all 
forms were incorporated onto the Intranet, the data modeling research was performed and 
is included in Appendix D for use in future development efforts. 
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vm. CONCLUSION 



A. INTRODUCTION 

The amounts of business and technical research required for intranet development 
is extensive, and despite the vast amounts of data analysis accomplished within this thesis, 
there are many more facets which must be considered before an effective intranet can be 
employed at a government installation. Since the design and implementation phases of this 
project will be accomphshed by a different thesis student jointly working on this project, 
discussions of such material will be left for presentation within that thesis. Nonetheless, a 
brief discussion of business policy, need for organizational learning, security, and lessons 
learned will be provided as the conclusion to this thesis. 

B. BUSINESS POLICY 

The effects of government downsizing, restructuring, and streamlining have placed 
many new challenges on ESU Alameda, with one of the largest being the management of 
available time. Although much thought has been put into the conceptual design of this 
prototype intranet, it does not guarantee successful results without the creation of a well 
estabUshed policy for intranet use. While creativity must be encouraged, the organization 
must not allow a paradox to exist where the pubUshing of artistic work becomes more 
important than the information itself In other words, the policy must continually weigh 
the benefits of the intranet against the costs of its use and make policy adjustments for any 
area which fails to meet the original intent of application. 
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C. ORGANIZATIONALLEARNING 



The ESU command must recognize that the use of an intranet will create a 
technologically driven paradigm shift within the organization. Since this will be a new 
experience for the majority of the organization, it will therefore require some amount of 
organizational learning to be successful. Although some members will find the concept of 
intranet collaboration easy, others will have a difficult time adopting to this new way of 
business for various reasons. One reason this difficulty exists is found in the impeding 
mental models of the individual users. Depending on the extent of these mental models, 
individual users could unintentionally restrict system functionality and defeat the intrinsic 
purposes of the intranet. One reason this is true is because the mental model is tacit and 
exists below any level of user or command awareness. Therefore, it is highly 
recommended the command meet with small groups of users before implementing the 
intranet to examine the mental models of the organization and sell the concept of intranet 
use. Once the organization recognizes and challenges their own mental models, true 
organizational learning can begin. So simply put, even if a user is forced to comply with 
intranet use, the fuU advantages of the intranet will not be recognized until each user 
challenges their own mental models and enables uninhibited organizational learning. 
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D- SECURITY 



Several different types of hardware and software security products exists to meet 
the operational requirements of ESU Alameda, many of which the organization may 
already be aware of in using the Microsoft Windows NT networking platform. Although 
it is not the intent of this thesis to forecast the future security requirements of ESU 
Alameda, or to choose the optimum mix of hardware and software products on the market 
to meet these requirements, we would like to introduce the reader to the types of common 
security measures available and briefly describe how ESU Alameda may use them if so 
desired. The common security measures include: 

♦ Authentication 

♦ Access Control 

♦ Cryptography 

1. Authentication 

The function of the authentication process is to identify the user to the computer 
system by means of a password. For the computer system, this ensures the user is who 
they claim to be so proper access to restricted files can be managed. For the user, this 
prevents the need to sign into multiple systems local and remote systems, since the 
authentication process is only required once for each session. During the design of the 
intranet, at least four stages of generic authentication should be implemented for the 
following reasons; 



♦ Firewalls 

♦ System Integrity 

♦ Auditing 
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a. Administrative, for overall administration of the intranet 

b. Command, for signature control of the CO and XO 

c. Supervisor, for signature control of division supervisors 

d. User, for signature control of individual users. 

Additional control could be implemented if each user was provided individual access 
privileges, however, this would create additional administrative maintenance issues which 
may not be warranted for ESU Alameda. 

2. Access Control 

The primary role of access control within each intranet apphcation will be to 
enable signature authority and possibly viewing privileges based on the command position 
held within the organization. Since there exists little need to establish and manage a 
system for individual access control, a generic system could be used to minimize the 
administrative burden of the command. This is possible because there exists a since of 
trust within the ESU organization. For this reason, the combined use of authentication 
and access control will prevent the accidental authorization of intranet request by junior 
command members for such things as leave requests and supply budget authorization 
forms. It is this feature that will compare a users logged in authorization against the 
access control level associated with the various form sections within the intranet. 

3. Cryptography 

Cryptography is primarily used when sending sensitive data across an unsecured 
network. There are various types employed, with each offering a mechanism to scramble 
the data in a way that only the intended user can unscramble and read it. Since ESU 
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Alameda is not operating in a highly secure environment, the need for the additional 
functionality of cryptography above that already provided by commercially available free 
web browsers is not required. 

4. Firewalls 

The primary purpose of firewalls is to protect the safety of a site against malicious 
attack from personnel outside the organization. Since ESU Alameda should use an 
extranet to share information with customers, as well as allow internet access for 
employee research, the use of a firewall is highly suggested. Since there are numerous 
different types of firewalls, as well as pricing and maintenance considerations to consider, 
we suggest ESU Alameda hire a professional firewall provider to ensure the firewall is 
properly selected, initialized, tested, and maintained. 

5. System Integrity 

The need for integrity protection is similar to the need for cryptography. Any time 
data is sent across an unsecured network, there exist the possibility someone can read the 
data if it is not encrypted. A potentially worse case scenario would be if the data were 
altered and then sent to the intended person. By using one of the many types of integrity 
methods, each member possesses assurance that the data came unaltered from the person 
claimed. For similar reasons as cryptography, this functionality is already adequately 
provided for ESU Alameda within the web browsers and is not considered an additional 
requirement for intranet development. 
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6. Auditing 

By enabling auditing an organization can log all attempts made to access the 
intranet or extranet system. In addition to tracking the number of unauthorized access 
attempts made to the system for security monitoring, the command could also measure the 
access to published data to see if the data published was worth the efforts to make it. 
Because ESU Alameda will be using Microsoft Windows NT Server, they already possess 
the ability to turn this feature on and off, and therefore do not require further development 
as part of the intranet design. Since the use of this feature has a negative impact on 
systems performance, it should only be enabled when a need exists, and then disabled at 
again at the first opportunity. 

E. LESSONS LEARNED 

This section provides the reader with some of the lessons learned while designing 
this project. It is primarily intended to assist future designers of such an application. 

1. Need For Positive Designer And Customer Relations 

We were extremely fortunate to find a customer who was extrinsically and 
intrinsically motivated to discuss new business opportunities. Because of the complexities 
and difficulties experienced with data analysis, this project would not have succeeded if 
not for the ongoing feedback the ESU crew provided. It is strongly recommended that 
only customers with this commitment be considered for business analysis considerations. 
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2. Need To Understand The Scope Of The Project 

A project of this sort is a huge undertaking capable of quickly developing into a 
task much larger than anticipated or desired for the limited development time available. 
When starting such a project, recognize the following; 

♦ Team members will differ in opinion, requiring additional research and rework 
of completed tasks. Although this is good for the design of the finished 
product, it took more time than anticipated and was a major factor in delays 

♦ Product design goals will change much more than anticipated. Changes come 
from the unit as well as other team members. This has similar effects as the 
previous bullet and is another cause for unplanned delays. 

♦ Team members become tunnel visioned. By definition of the rapid prototype 
development, the system is not designed to work. However, in retrospect we 
found we spent days fixing designs which previously worked, or which we 
couldn't get to work suitable for a finished product. More emphasis needs to 
be placed on rapid prototyping instead to prevent it fi'om turning into the build 
and fix methodology. 

3. Need For Skills Development 

With more than 2000 pages of text read in preparation for this project, much more 
time was required to gain the needed skills than was anticipated. We suggest you 
quadruple the time allotted for this task. 
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4. Software Bugs Or Restrictions Of Use 

Attempting to resolve software bugs and limitations of student edition CASE tools 
provided this team the largest amount of fmstration for the entire project. Before starting 
such a project, preview applicable newsgroups and web sites to gain an understanding of 
the software constraints you will come across before you spend days trying to solve a 
problem that you can not fix. 

5. Need For Patience And Pacing 

In attempts to make up the lost time associated with software bugs, longer learning 
curves than anticipated, delays associated with reengineering efforts, and the teams 
intrinsic desire to resolve all encountered problems, team members began to get restless 
and began working abnormal hours in attempts to catch up. Fatigue made matters worse 
and eventually the perceived scope of the project was scaled back to an obtainable level, 
more in lines with the original projections. It is highly recommended that future teams 
taking on this type of project accept these delays and learn to use them as positive learning 
experiences instead of failures to meet obhgations. We feel adjusting to these fhistrations 
and enhancing team management skills to be one of the biggest lessons learned in this 
project. 
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F. CONCLUSION 



Although the thesis analyzed the existing business models, data flows, and 
technical aspects required for intranet development, additional work will still be required 
by ESU Alameda to enable the organization to learn and accept the new policies and 
operating procedures. As a conclusion to this thesis, the reader was provided several 
types of security systems available for consideration as well as a list of our lessons learned 
to aide in future design capabilities. 
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APPENDIX A. TRIP REPORT 



Subject: Initial visit to ESU Alameda, Alameda California, 4-7 December 1998 



Team Members: LT Benhart 

LT Dardis 
LT Hannah 



NPS Student (USCG) 
NPS Student (USCG) 
NPS Student (USCG) 



Purpose: Familiarization with ESU Alameda’s functions, processes, challenges, goals. 



and requests for the development of a prototype Intranet specification. 



People Contacted: Dean Waring 

CDR Lane 
LCDR Hernandez 
LT Nelson 
LTJG Raush 
CW04 Weldon 
CW03 Ward 
CW02 Olsen 
TCCS Clarke 
SKC Bennett 
ETC Bartlett 
GS12 Gainer 
GS 12 Usher 
GSll Spiva 
GS9 Wallace 



ESU Coordinator (ESU’s Boss) 

CO 

XO 

Computer Branch Chief 

Electronics Branch Chief 

Shore Section Supervisor 

Telecommunications Section Supervisor 

Vessels Section Supervisor 

Frequency Manager 

Storekeeper 

Alternate Contracting Representative 
Computer Support Section Supervisor 
Networks Section Supervisor 
Contracting Representative 
Telecommunications Manager 



Upon arrival, LT Benhart, LT Dardis of the specification development team and 
LT Hannah of the applications development team conducted an initial briefing with the 
Commanding and Executive Officer. Points of topic included establishing the objectives 
of the project, limiting expectations of the unit, and providing background information on 
team members. The command provided the team with unit familiarization, command and 
control oversight, existing command challenges, current state of fluctuation relative to a 
streamlining initiative, political profile, existing stakeholders, and hardware/software 
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design constraints. Schedules were established for a more detailed interviews later in the 
day. 

Due to limited available time the initial plan of the team was to collect specific 
requirements by interviewing top management, and to gather existing forms, applications, 
and written procedures to study data. Existing procedures and divisional challenges were 
to be determined by conducting group interviews with key workers and middle managers, 
then using questionnaires to collect specific process information fi-om these members. 
Constraints: ESU Alameda recently received new Pentium based computers which will 
be upgraded to a Microsoft Windows NT 4.0 and Office 97 networked platform. Since 
this hardware and software will be the supported standard for Coast Guard Units, it will 
be used for project development. 

Lessons Learned: More time was required than anticipated to gather the required 
information. The use of questionnaires was a fiiiitless effort offering no benefit to this 
project. This is primarily because the employees did not fully understand what information 
the team wanted, felt they could not adequately transcribe their changing roles, and felt 
their processes were uniquely event driven each day. To work around this challenge, the 
team conducted a quick training session on the use of data flow diagrams (DFDs) and 
iteratively used this tool in a group environment to transcribe daily routines on large 
drawing boards. With the team acting as facilitators and transcribing the needed data 
during group conversations, detailed process evaluations were enabled. 
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To assess project risk, a testing of the political environment was performed by 
discussing the concept of a prototype Intranet with all levels of the organization, as well as 
critical stakeholders external to the organization. No political problems were identified. 
Conclusion: ESU Alameda is an innovative organization that could benefit from Intranet 
technology. The command is extremely willing to use new technologies, modify business 
processes, and take risks in attempts to enhance customer service. In addition, they are 
both intrinsically and extrinsically motivated to tackle the learning challenges of Intranet 
use. 

The teams obtained extensive information that must now be analyzed and refined. 
Open communications were established between team members and critical employees of 
the command for prototype feedback and data refinement. 

The team would like to thank the crew of ESU Alameda for taking the time to 
assist them with this project. We hope we can all benefit from this experience. 
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APPENDIX B DATA FLOW DIAGRAMS 
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Context Level Diagram B.l- COTR Modifications 
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Level 0 Data Flow Diagram B.2 - COTR 
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Context Level Diagram B.3 - Shore Section Chief CASREP 
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Level 0 Data Flow Diagram B.4 - Shore Section Chief CASREP 
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Context Level Diagram B.5 - COTR CASREP 
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Level 0 Data Flow Diagram B.6 - COTR CASREP 



132 



APPENDIX C PROCESS DESCRIPTIONS 



LEAVE REQUEST 

Context Level Diagram Description (Figure 6.6): The Leave Request process 
enables a person to request leave, and gain approval from immediate supervisors and 
finally the Executive Officer for final approval to take requested leave. 

Process 1.0 Description (Figure 6.7); This process documents the request for 

leave. 

1 . What entities does this process effect? People requesting leave. 

2. How many users does this process have? One. 

3. Who is the primary owner of this process? Person requesting leave. 

4. How often is this process used? On average, someone executes this process 
within the command several times each month. 

5. How often is this process updated? Same as No. 4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. Most requests come in 
the form of email. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. 

8. What is the source of information for this process? The person requesting 
leave initiates the process. 
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9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished by sending email to and from 
the supervisor, the supervisor's supervisor, and the Executive Officer until the 
request is either approved or denied. 
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LEAVE REQUEST 



Process 2.0 Description (Figure 6.7): This process transfers the request from 
person to person with the email files acting as the archive for leave taken. 

Process 2.1 Description (Figure 6,8): This determines the days of leave to 
request and fills out the leave form. 

1 . What entities does this process effect? People requesting leave. 

2. How many users does this process have? Everyone at the command. 

3. Who is the primary owner of this process? People requesting leave. 

4. How often is this process used? On average, someone executes this process 
within the command several times each month. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. 

8. What is the source of information for this process? The person requesting 
leave initiates the process. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually/mentally. 
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LEAVE REQUEST 



Process 2.2 Description (Figure 6.8): This process initiates the email for leave 
request for the person requesting leave, immediate supervisor, additional supervisor, and 
finally the Executive Officer for final approval or denial. 

1. What entities does this process effect? The people requesting leave, 
supervisors, and Executive Officer. 

2. How many users does this process have? Everyone at the command. 

3. Who is the primary owner of this process? The people submitting the leave. 

4. How often is this process used? On average, someone executes this process 
within the command several times each month. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information is 
unclassified but sensitive. The volume of information will be changed fi'om day 
to day. 

8. What is the source of information for this process? The person requesting 
leave initiates the process, everyone else reviews, comments, and forwards the 
request. 

9. What is the current status of the process? This process is currently not on the 
ESU Intranet and is manually accomplished. Email is used. 
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LEAVE REQUEST 



Process 2.3 Description (Figure 6.8): This process monitors the leave request in 
a waiting pattern for an answer. 

1 . What entities does this process effect? The people requesting leave, 
supervisors, and Executive Officer. 

2. How many users does this process have? Everyone at the command. 

3. Who is the primary owner of this process? People requesting leave. 

4. How often is this process used? On average, someone executes this process 
within the command several times each month. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information is 
unclassified but sensitive. The volume of information will be changed from day 
to day. 

8. What is the source of information for this process? The person requesting 
leave waits for supervisor's input as well as final approval. Feedback in needed 
for the requesting person to know that the supervisor has forwarded the request 
without taking personnel time. The same process holds true once the 
supervisor(s) forward the request and wait for the decisions from the above chain 
of command. 
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9. What is the current status of the process? This process is currently not on the 
ESU Intranet and is mentally accomplished by the initiator and all supervisors. 
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PARTS ORDERING 



Context Level Diagram Description (Figure 6.9): The function of the Parts 
Ordering process is to act as focal point for all of the command parts request, including 
budget verification, quality control, ordering, tracking, forecasting, and transportation of 
materials. This process is the cornerstone to making the command operate efficiently and 
is the number one request of the command to attempt to resolve. 

1. Process 1.0 Description (Figure 6.10): This process verifies all requests are in 
the proper format and are requesting proper quantities. 

2. What entities does this process effect? ESU branch personnel. 

3. How many users does this process have? All ESU employees (90-100). 

4. Who is the primary owner of this process? The unit Storekeeper (SK). 

5. How often is this process used? This process is executed several times per day. 

6. How often is this process updated? Same as No.4. 

7. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. Most requests come in the 
form of email, message traffic, and forms. 

8. What type of information does this process use? Most of this information is 
unclassified but sensitive. The volume of traffic will change from day to day. 

9. What is the source of information for this process? The technician reports 
parts requirements and priorities. 
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10. What is the current status of the process? This process is currently not on the 
ESU Intranet and is manually accomplished. Updates are done in numerous ways 
including written logs and word processing, spreadsheets, and forms. All of this 
information is available, but will be difficult to pinpoint without a prototype 
design for Intranet use. 

11. Time Used: Currently the unit SK spends 25% of his time informing command 
personnel on the status of parts orders. 
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PARTS ORDERING 



Process 2.0 Description (Figure 6.10): This ensures adequate funds are available 
before parts are purchased, manually files paperwork to track finding, manually logs 
ordering details, and manually enters parts request in a proprietary parts ordering 
computer network system. 

1. What entities does this process effect? ESU Executive Officer (XO) and 
ESU employees. 

2. How many users does this process have? The SK is the sole performer of 
this task, but it is done for every member of the command. 

3. Who is the primary owner of this process? The unit SK. 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? The ESU branches will 
request the parts, the XO will authorize the funding, and the SK will provide 
all other input. 
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9. What is the current status of the process? This process is currently not on 



the ESU Intranet and is manually accomplished. 
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PARTS ORDERING 



Process 3.0 Description (Figure 6.10): This process determines the proper type 
of procurement for the requested part (Purchase Request, GBL, VISA, or MILSTRIP), 
and logs details into a log network system. 

1. What entities does this process effect? Transport Office, Finance Office 

(F). 

2. How many users does this process have? The SK is the sole performer of 
this task, but it is done for every member of the command. 

3. Who is the primary owner of this process? The unit SK. 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? A variety of United 
States Coast Guard regulations govern the proper ordering procedures. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 
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PARTS ORDEREVG 



Process 4.0 Description (Figure 6.10): This process determines which supplier 
the part(s) should be ordered from depending on the source of funding (VISA or 
MILSTRIP). 

1. What entities does this process effect? Supplier. 

2. How many users does this process have? The SK is the sole performer of 
these tasks, but it is done for every member of the command and for every 
part ordered. 

3. Who is the primary owner of this process? The unit SK. 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No. 4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? A variety of United 
States Coast Guard regulations govern the proper ordering procedures. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 
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PARTS ORDERING 



Process 5.0 Description (Figure 6.10); This process performs a quality control 
check of received orders to ensure the proper type of part, quantity, and physical 
condition before transport to the requested location. 

1. What entities does this process effect? Transport Office, ESU employees. 

2. How many users does this process have? The SK is the sole performer of 
these tasks, but it is done for every member of the command. 

3. Who is the primary owner of this process? The unit SK. 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use h? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? A paper log and 
physical inspection. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 
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PARTS ORDERING 



Process 6.0 Description (Figure 6.10); This process manually fills out the 
MILSTRIP paperwork. 

1. What entities does this process effect? None directly. 

2. How many users does this process have? The SK is the sole performer of 
this task, but it is done for every member of the command each time a 
MILSTRIP part is requested. 

3. Who is the primary owner of this process? The unit SK. 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No. 4. 

6. What is the mode of use for this process by the entities that use it? The 
SK manually fills out this form for archival purposes. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change fi’om day to 
day. 

8. What is the source of information for this process? Parts catalogues and a 
variety of United States Coast Guard regulations govern the proper ordering 
procedures. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 
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PARTS ORDERING 



Process 7.0 Description (Figure 6.10): This process determines the proper type 
of procurement for the requested part (Purchase Request, GBL, VISA, or MILSTRIP), 
and logs details into a log. 

1. What entities does this process effect? Transport Office, Finance Office 

(F). 

2. How many users does this process have? The SK is the sole performer of 
this task, but it is done for every member of the command. 

3. Who is the primary owner of this process? The unit SK. 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7 What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? A variety of United 
States Coast Guard regulations govern the proper ordering procedures. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 
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PARTS ORDERING 



Process 8.0 Description (Figure 6.10): This process occupies 25% of the SK's 
time and verifies/monitors the status of all open parts orders, providing feedback to the 
appropriate entities. 

1. What entities does this process effect? Transport Office, ESU employees. 
Supplier 

2. How many users does this process have? The SK is the sole performer of 
these tasks, but it is done for every member of the command for every part 
that is ordered. 

3. Who is the primary owner of this process? The unit SK. 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No. 4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries, mainly by phone, email, 
and in person. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change fi'om day to 
day, but occupies a large part of the SK's duties. 
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8. What is the source of information for this process? The sources of 
information are extremely large, including shippers, vendors, sources of 
supply, and other military sources. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. This is the top area requested 
for development that would help free up some of the time spent updating 
personnel. 
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COTR MODIFICATIONS 



Context Level Diagram Description (Figure Appendix B.l); The function of 
the ESU COTR as it pertains to contract Modifications is to act as an intermediary 
between Coast guard conunands (Operational and Maintenance) and the additional 
services requested under a service contract. This function legally protects the 
government and ensures the contractor is paid or penalized for services rendered under 
the scope of the contract. Since only the Contracting Officer can make changes to the 
contract. The COTR will lobby all requests and make recommendations to the 
Contracting Officer for contract modification. 

1. Process 1.0 Description (Figure Appendix B.2); This process logs all 
service requests for services outside the scope of the existing contract. 

2. What entities does this process effect? USCG Eleventh District operational 
units, USCG Support Commands, Contractors, Contracting Officer. 

3. How many users does this process have? The ESU COTR staff performs 
this process (less than ten). 

4. Who is the primary owner of this process? The COTR. 

5. How often is this process used? This process is executed on a weekly basis, 
and sometimes more frequently. 

6. How often is this process updated? Same as No.4. 

7. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. Most requests come in 
the form of letters, messages, phone calls, and email. 
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8. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

9. What is the source of information for this process? The operational units 
are responsible for reporting operational service requirements, as then- 
operational needs change. 

10. What is the current status of this process? This process is currently not in 
use on the ESU Intranet and is manually accomplished. Updates are done in 
numerous ways including written logs and word processing. All of this 
information is not directly available and is a complex web of resources 
involving information controlled by outside entities, mainly being the 
Contracting Officer assigned to a different organization than the ESU. 
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COTR MODIFICATIONS 



Process 2.0 Description (Figure Appendix B.2): This process logs all service 
requests for services outside the scope of the existing contract. 

1 . What entities does this process effect? USCG Eleventh District operational 
units, USCG Support Commands, Contractors, Contracting Officer. 

2. How many users does this process have? The ESU maintenance personnel 
perform this process. 

3. Who is the primary owner of this process? The COTR. 

4. How often is this process used? This process is executed on a weekly basis, 
and sometimes more frequently. 

5. How often is this process updated? Same as No.4 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? The COTR will 
determine if a need exists for immediate service request and whether it should 
be forwarded as a request for permanent contract modification. 
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SHORE SECTION (CASREPSl 



Context Level Diagram Description (Figure Appendix B.3): The function of 
the Shore Section Chief in regards to CASREP response is to quickly resolve the 
problem. This can be done by using Coast Guard members who work directly for him, or 
with other ESU branches to gain contract assistance. 

Process 1.0 Description (Figure Appendix B.4): This process logs all submitted 
CASREPS with the AOR of the Shore Section Chief for archival purpose. 

1. What entities does this process effect? ESU branch personnel within the 
AOR of the Shore Section Chief (i.e. they work for him). 

2. How many users does this process have? All ESU Shore Section 
employees. 

3. Who is the primary owner of this process? The Shore Section Chief 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No. 4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. Most requests come in 
the form of email and phone calls. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 
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8. What is the source of information for this process? The ESU Shore 
Section member performing the service desk duty function for that day 
(service desk duty revolves on a weekly basis). 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. Updates are done in 
numerous ways including written logs, forms, and self-made databases. All of 
this information is available, but will be difficult to pinpoint without a 
prototype design for Intranet use. 
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SHORE SECTION (CASREPS) 



Process 2.0 Description (Figure Appendix B.4); This process determines the 
priority of response and actions to be taken for a given CASREP. 

1 . What entities does this process effect? Indirectly the unit with the problem. 

2. How many users does this process have? The Shore Section Chief is the 
primary user of this process, although his crew often reviews it for work 
details. 

3. Who is the primary owner of this process? The Shore Section Chief 

4. How often is this process used? This process is executed several times per 
day. 

5. How often is this process updated? Same as No. 4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? The input fi'om the 
source of the CASREP that is stored in a service log by a service desk 
employee. The priority is determined by information known to the Shore 
Section Chief that is not documented anywhere (i.e. importance of outage 
relative to other outages). 
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9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually/mentally accomplished. 
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SHORE SECTION fCASREPS) 



Process 3.0 Description (Figure Appendix B.4); This process monitors all open 
CASREPs and revises priorities as needed. 

1. What entities does this process effect? Indirectly the ESU employees and 
unit with the problem. 

2. How many users does this process have? The Shore Section Chief is the 
primary user of this process, although his crew often reviews it for work 
details. 

3. Who is the primary owner of this process? The Shore Section Chief. 

4. How often is this process used? This process is executed daily. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? The ESU service desk 
receives requests for changes and updates the CASREPs Storage Log. The 
Shore Section Chief only reviews the CASREP Storage Log to monitor status. 
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9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. A self made database is 
used. 
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SHORE SECTION fCASREPS) 



Process 4.0 Description (Figure Appendix B.4): This process determines what 
type of action should be accomplished to resolve the casualty. 

1 . What entities does this process effect? ESU COTR, Eleventh District Unit 
with CASREP. 

2. How many users does this process have? The Shore Section employees 
perform this task for every CASREP that is submitted for repair. 

3. Who is the primary owner of this process? The Shore Section Chief 

4. How often is this process used? This process is executed several times a 
day. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? The priority 
established by the Shore Section Chief and current funding and parts 
constraints. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is mentally accomplished by the responding technicians. 
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SHORE SECTION fCASREPS) 



Process 5.0 Description (Figure Appendix B.4): This process performs an 
archival of technical information to attempt to provide some source of a knowledge base 
for technicians. 

1. What entities does this process effect? Indirectly, all entities that are 
supported by the ESU. 

2. How many users does this process have? All members of the Shore Section 
as well as the COTR. 

3. Who is the primary owner of this process? The Shore Section Chief 

4. How often is this process used? This process is executed daily. 

5. How often is this process updated? Same as No.4. 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? Technicians. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 
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SHORE SECTION (CASREPS) 



Process 6.0 Description (Figure Appendix B.4): This process determines which 
parts are required for order. 

1 . What entities does this process effect? None directly. 

2. How many users does this process have? All ESU Shore Section 
employees. 

3. Who is the primary owner of this process? The Shore Section Chief 

4. How often is this process used? This process is executed daily. 

5. How often is this process updated? Same as No.4 

6. What is the mode of use for this process by the entities that use it? Forms 
and techniczd publications. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? Parts catalogues and a 
variety of Coast Guard regulations govern the proper ordering procedures. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 
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SHORE SECTION fCASREPS> 



Process 7.0 Description (Figure Appendix B.4); This process determines 
funding requirements to resolve a CASREP and request funding as they are needed. 

1 . What entities does this process effect? The unit with the CASREP, the ESU 
SK, and the ESU XO. 

2. How many users does this process have? All ESU Shore Section 
employees. 

3. Who is the primary owner of this process? The Shore Section Chief. 

4. How often is this process used? This process is executed daily. 

5. How often is this process updated? Same as No.4 

6. What is the mode of use for this process by the entities that use it? This 
process is manually performed with email being the prime source of 
communications. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? A variety of Coast 
Guard regulations govern the proper ordering procedures and funding 
guidelines. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 
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SHORE SECTION (CASREPS) 



Process 8.0 Description (Figure Appendix B.4): This process identifies 
alternate sources of test equipment needed to resolve CASREPs when otherwise not 
available. 

1. What entities does this process effect? Transport Office, ESU SK. 

2. How many users does this process have? All Shore Section employees. 

3. Who is the primary owner of this process? The Shore Section Chief 

4. How often is this process used? This process is executed weekly. 

5. How often is this process updated? Same as No. 4 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. 

8. What is the source of information for this process? The sources of 
information are extremely large, including shippers, vendors, sources of 
supply, and other military sources. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. 



163 



COTR CASREP 



Context Level Diagram Description (Figure Appendix B.5): The function of 
the ESU COTR as it pertains to CASREP response and service requests is to act as an 
intermediary between Coast Guard commands (operational and maintenance) and the 
contractor chosen to perform certain contracted duties. This function legally protects the 
government and ensures the contractor is paid or penalized for services rendered under 
the scope of the contract. 

Process 1.0 Description (Figure Appendix B.6): This process decides whether a 
request for maintenance falls under the contract for contractor resolution or under Coast 
Guard maintenance responsibility. The selected source of maintenance is then told to 
perform a function to resolve the maintenance casualty. Feedback amongst entities is 
exchanged for updating purposes. For some functions the contract will have primary 
responsibility with Coast Guard military members acting as secondary response source if 
the contractor is unable to respond. The opposite applies to areas involving the Coast 
guard as the primary maintenance source, where payment for extraneous contractor 
services is paid under the guidelines of the contract. All information is archived in a data 
store for monthly review to determine modifications required for contractor payments. 

1. What entities does this process effect? USCG Eleventh District operational 
units, USCG support commands, the contractor. 

2. How many users does this process have? The ESU COTR staff performs 
this process (less than ten). 
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3. Who is the primary owner of this process? COTR. 

4. How often is this process used? This process is executed on a daily basis, 
sometimes more frequently. As the status of electronic repair changes, the 
members will report that information to the process. 

5. How often is this process updated? Same as No. 4 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? The operational units 
are responsible for reporting equipment casualties and operational conditions 
as it changes. The Coast Guard maintenance and contractor staffs report 
repair efforts and response capabilities. The maintenance contract is used to 
determine response guidelines. 

9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. Updates are done in 
numerous ways including written logs, word processing, spreadsheets, and 
some databases. All of the information is not directly available and is a 
complex web of resources. 
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COTR CASREP 



Process 2.0 Description (Figure Appendix B.6): This process allocates Coast 
Guard maintenance personnel with the ESU to act as a secondary response team to 
contracted services as required to meet operational needs. 

1 . What entities does this process effect? USCG Eleventh District operational 
units, USCG support commands, the contractor. 

2. How many users does this process have? The ESU maintenance personnel 
perform this process. 

3. Who is the primary owner of this process? COTR. 

4. How often is this process used? This process is executed on a daily basis, 
sometimes more frequently. As the status of electronic repair changes, the 
members will report that information to the process. 

5. How often is this process updated? Same as No.4 

6. What is the mode of use for this process by the entities that use it? This 
process uses multiple updates and multiple queries. 

7. What type of information does this process use? Most of this information 
is unclassified but sensitive. The volume of traffic will change from day to 
day. 

8. What is the source of information for this process? The COTR will 
determine if a need exists for a secondary response service request. 
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9. What is the current status of the process? This process is currently not on 
the ESU Intranet and is manually accomplished. Updates are done in 
numerous ways including written logs, word processing, spreadsheets, and 
some databases. Phones are mainly used to disseminate information. 
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APPENDIX D DATABASE FORMS 




Figure D.l - Bill Of Lading Status Log 




Figure D.2 - Visa Number Update Form 
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Figure D.3 - Purchase Request Visa Order Form 




Figure D.4 - Program Element Input form 
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Figure D.5 SURF Status Log Input Form 




Figure D.6 - Unit Cost Center Update Form 
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SURF REQUISITtOH log 
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Figure D.7 - SURF Requisition Log Form 
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Figure D.8 - Bill Of Lading Form 
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APPENDIX E GLOSSARY OF TERMS 



AOR (Area of Responsibility) 

CASE Tools (Computer-Aided Software Engineering) 

Software tools that provide automated support for some portion of the systems 
development process. 

CASREP (Casualty Report) 

This is a form that is submitted to U.S. Coast Guard Maintenance and Logistic units to 
request assistance in the repair of faulty equipment. 

CGI (Common Gateway Interface) 

A technology used to build dynamic WWW documents. 

COTR (Contracting Officers Technical Representative) 

COTS (Commercial Off The Shelf) 

COTS is intended to reduce acquisition cycle time, provide access to state-of-the-art 
technology, increase competition, and provide lower costs to the purchaser. 

DFD (Data Flow Diagram) 

A graphical display that illustrates business processes and data interfaces from a data 
perspective. 
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ESU (Electronic Systems Support Unit) 

A U.S. Coast Guard facility that maintains and supports all facets of Coast Guard 
electronic equipment. 

ET (Electronics Technician) 

An enlisted rating that is responsible for the repair and maintenance of sophisticated 
electronics equipment, radio receivers and transmitters, radar, navigation equipment, and 
computer equipment. 

FDDI (Fiber Distributed Data Interface) 

A LAN technology that uses fiber optics to connect computers on a ring technology 
(lOOMbits/s). 

FTP (File Transfer Protocol) 

A protocol used to transfer a complete file from one computer to another. 

Gopher 

A software that provides a menu for accessing Internet resources. 

GUI (Graphical User Interface) 

A GUI replaces the keyboard commands typical of old-fashioned computers with point- 
and-click buttons and menus. 
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HTML (Hypertext Markup Language) 

The code which is used to create and display information on the WWW. 

HTTP (Hypertext Transfer Protocol) 

The protocol used to transport a WWW page from one computer to another, 
me (Internet Relay Chat) 

Facilitates conversations over the Internet in close to real time. 

LAN (Local Area Network) 

A network of computers that transmits data along a single shared medium in a small 
geographical area (i.e. a single office building or college campus). 

MAU (Media Access Unit) 

It is a piece of equipment that adapts or formats a signal for transmittal over a 
communication medium, (i.e. an optical transmitter), which accepts an electrical signal at 
its input port and converts it to an optical signal accessible at its output port. 

MIME (Multipurpose Internet Mail Extensions) 

A mechanism that allows nontext data to be sent in a standard email message. 
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MLCLANT (Maintenance & Logistics Command Atlantic) 

The Coast Guard Maintenance & Logistics Command Atlantic supports Atlantic Area 
operational readiness by ensuring that Coast Guard vessels and shore activities are fully 
capable of meeting their assigned missions. To accomplish this, MLCLANT provides a 
broad range of engineering, personnel, health and safety, financial management, and legal 
program support. 

MLCPAC (Maintenance & Logistics Command Pacific) 

The Coast Guard Maintenance & Logistics Command Pacific supports Pacific Area 
operational readiness by ensuring that Coast Guard vessels and shore activities are fully 
capable of meeting their assigned missions. To accomplish this, MLCPAC provides a 
broad range of engineering, personnel, health and safety, financial management, and legal 
program support. 

SK (Storekeeper) 

An enlisted rating responsible for providing and accounting for the constant stream of 
supplies, clothing, commissary items and spare. 

TAD (Temporary Additional Duty) 

TCP/IP (Transmission Control Protocol/Internet Protocol) 
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The collection of transport and application protocols used to communicate on the Internet 
and other networks. 

Telnet 

Allows a user to log on from a remote computer. 

TT (Telephone Technician) An enlisted rating responsible for the installation and 
maintenance of many types of telecommunications equipment. The office that the 
technician is assigned to is often referred to as the TT shop. 

URL (Uniform Resource Locator) 

An address or location of a site to be viewed on the WWW. 

WAN (Wide Area Network) 

A network of computers that transmits data along a single shared medium in a large 
geographical area (i.e. can span multiple cities). 

WWW (World Wide Web) 

Computers which are linked and which provide hyperlinks to Internet resources 
worldwide. 
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